Windows server 2016 не пингуется при отключенном брандмауэре

• Remove From My Forums

При отключение брандмауэра сервер не виден в сети.

• Общие обсуждения

• В домене политиками запрещено запускать службу Брандмауэр Windows. После видимо каких то обновлений, ибо ничего не менялось больше в конфигурации сети. В один прекрасный момент, денй 5 назад перестало в сети видиться несколько серверов. Ни пингуются, ни
  терминалом .. никак. Включили службу брандмауэра — все чудесным образом заработало. Пришлось убрать из политик отключение службы. То есть сейчас при полностью остановленной службе, вся сетевая активность прекращается. Что это может быть?

  Да.. Такое еще происходить и на машине с Windows 7 у меня например. Службы сетевые все проверял, все работает. Те, что от нее зависят тоже все работает.

  • Изменен тип

    4 января 2011 г. 11:07
    нет реакции

  • Перемещено
    Yubo. Zhang
    21 апреля 2012 г. 17:27
    merge forums (От:Windows Server 2008)

I’m having a bizarre issue with the windows firewall that I can’t pin down.

I have 2 Windows Server 2016 systems that run a RADIUS service on UDP port 1812. The RADIUS service is for our Duo Multi-Factor Authentication proxy which basically connects Duo to our Domain Controller. We use an F5 load balancer to load balance the RADIUS
traffic to both servers if they are both up. In order to monitor if they are both up, we use F5’s UDP health monitor. The UDP health monitor sends in UDP requests to see if a UDP service is listening. When the service is listening, the server send nothing
back to these requests (as it should). When the service is not listening, the server is supposed to send an ICMP destination unreachable (type 3, code 3) to inform the load balancer that there is no service listening on that port. This means the server we’re
monitoring should tell us if the UDP service is down (assuming the server itself is up). We also use a ping monitor to ensure the server itself is up. This is how F5 recommends health monitoring be configured for UDP services.

The issue is that the server doesn’t send an ICMP destination unreachable if the firewall is on. If I turn the firewall off, then it works fine. The obvious answer would be that the firewall is blocking the ICMP unreachable, but I can’t understand why.

Firewall Off -> ICMP unreachable is sent as it should
Firewall On -> No ICMP unreachable is sent
Firewall On + no GPO or local block rules in place -> No ICMP unreachable is sent
Firewall On + no block rules + rules to allow all outbound and inbound connections -> No ICMP unreachable is sent
Firewall On + no block rules + allow any rules + allow specifically ICMP unreachable outbound -> No ICMP unreachable is sent

Through all of this testing there are no dropped packets in the firewall log. I manually created a test rule to block outbound pings just to make sure the firewall log was working properly and logging dropped packets and those dropped packets were logged
as expected.

To sum everything up, I have the firewall setup to allow all inbound traffic, all outbound traffic, all outbound ICMP unreachables (explicitly), log all dropped traffic, and I still don’t see any ICMP unreachables leaving the server or being logged as dropped
packets in the firewall log. As soon as I turn off the firewall, it works fine and the ICMP unreachable is sent out.

To me this is very odd, it’s almost as if turning the firewall on breaks some portion of the IP stack that sends out the ICMP unreachables when a UDP packet is received on a closed UDP port. Any insight into this issue would be greatly appreciated.

• Edited by

  Friday, March 10, 2017 3:17 PM

I’m having a bizarre issue with the windows firewall that I can’t pin down.

I have 2 Windows Server 2016 systems that run a RADIUS service on UDP port 1812. The RADIUS service is for our Duo Multi-Factor Authentication proxy which basically connects Duo to our Domain Controller. We use an F5 load balancer to load balance the RADIUS
traffic to both servers if they are both up. In order to monitor if they are both up, we use F5’s UDP health monitor. The UDP health monitor sends in UDP requests to see if a UDP service is listening. When the service is listening, the server send nothing
back to these requests (as it should). When the service is not listening, the server is supposed to send an ICMP destination unreachable (type 3, code 3) to inform the load balancer that there is no service listening on that port. This means the server we’re
monitoring should tell us if the UDP service is down (assuming the server itself is up). We also use a ping monitor to ensure the server itself is up. This is how F5 recommends health monitoring be configured for UDP services.

The issue is that the server doesn’t send an ICMP destination unreachable if the firewall is on. If I turn the firewall off, then it works fine. The obvious answer would be that the firewall is blocking the ICMP unreachable, but I can’t understand why.

Firewall Off -> ICMP unreachable is sent as it should
Firewall On -> No ICMP unreachable is sent
Firewall On + no GPO or local block rules in place -> No ICMP unreachable is sent
Firewall On + no block rules + rules to allow all outbound and inbound connections -> No ICMP unreachable is sent
Firewall On + no block rules + allow any rules + allow specifically ICMP unreachable outbound -> No ICMP unreachable is sent

Through all of this testing there are no dropped packets in the firewall log. I manually created a test rule to block outbound pings just to make sure the firewall log was working properly and logging dropped packets and those dropped packets were logged
as expected.

To sum everything up, I have the firewall setup to allow all inbound traffic, all outbound traffic, all outbound ICMP unreachables (explicitly), log all dropped traffic, and I still don’t see any ICMP unreachables leaving the server or being logged as dropped
packets in the firewall log. As soon as I turn off the firewall, it works fine and the ICMP unreachable is sent out.

To me this is very odd, it’s almost as if turning the firewall on breaks some portion of the IP stack that sends out the ICMP unreachables when a UDP packet is received on a closed UDP port. Any insight into this issue would be greatly appreciated.

• Edited by

  Friday, March 10, 2017 3:17 PM