Several employees working from home can access the internet normally, but they suddenly can't reach their company headquarters. The affected users cannot ping the headquarters firewall, open its HTTPS or VPN portal, connect through SSL VPN, or access services behind it. Packet captures on the headquarters firewall show no traffic at all from their public IP addresses.
However, running Windows tracert to the same public IP appears to work, and the firewall sees the expected ICMP traffic from the traceroute. The same laptop works immediately when connected through a phone hotspot, and the headquarters firewall is reachable from other networks. DNS is not involved because the tests were also performed directly against the IP address. IPv6 was disabled without changing anything.
The affected users appear to be Telekom residential customers, although they use different service plans. What could allow traceroute traffic through while preventing normal ICMP, HTTPS, and VPN connections from reaching the destination?
4 Answers
Test the actual services instead of relying on ping: for example, use PowerShell Test-NetConnection against the firewall's HTTPS and VPN ports, and compare the results from the affected ISP, a working office connection, and the phone hotspot. Capture traffic on the client as well as the destination firewall to determine whether SYN packets leave the laptop and what address they use. If the traffic leaves normally but never arrives at headquarters, provide the ISP with timestamps, source and destination addresses, traceroute output, and packet captures.
Traceroute is not equivalent to a normal ping or a TCP connection. Windows tracert sends ICMP packets with deliberately increasing TTL values, causing intermediate routers to generate time-exceeded responses. A destination can allow those responses while dropping direct ICMP echo requests or traffic to ports such as HTTPS and the VPN portal. Also, Linux traceroute commonly uses UDP by default, so the exact behavior depends on the operating system and traceroute mode. Treat traceroute as evidence that some packets follow a route, not proof that the required service is reachable.
The hotspot result is the strongest clue: the laptop and headquarters firewall both work when the source network changes, so this is probably somewhere in the residential ISP path rather than an application or firewall rule. Compare the public source address, route, and protocol from an affected connection and a working one. The ISP may be filtering or misrouting traffic to that destination, or handling IPv4 through CGNAT/DS-Lite differently from other traffic. Ask the provider to investigate routing and filtering for the affected destination and source ranges.
CGNAT or DS-Lite could explain why direct ICMP behaves differently, but it would not normally prevent every VPN and HTTPS connection by itself. Check which VPN transport and ports are being used, whether the provider is filtering those ports, and whether the affected connections are actually exiting through the same public address for every protocol. A continuous traceroute or path comparison may reveal a route change or a problematic ISP edge router.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures