Some remote users can browse the web but cannot reach our main site's firewall, VPN, or web services. Ping to the firewall's IP fails, while traceroute appears to reach it and shows traffic at the firewall.
The same laptop works over a mobile hotspot. DNS resolves correctly, and testing the IP directly makes no difference. What should I check next?
First, check what the traceroute actually proves. Intermediate hops can return ICMP time exceeded messages even if the destination never responds. If the final hop does respond, compare the probe type with ping. Windows tracert normally uses ICMP echo requests with different TTL values, while other traceroute implementations may use UDP or TCP.
Different results can come from filtering or rate limiting along the path, not just a rule on the destination firewall. Capture on the laptop and the firewall at the same time. Check whether each probe leaves, reaches the firewall, and gets a reply. Note the source address seen at each end too, since NAT can change it.
The hotspot result is a useful clue. Compare the public source address and route on the home connection with the working connection. A provider filter, shared address, or security device upstream of the site firewall could affect one path without affecting the other.
Ask the firewall team to check for blocks or anti-DDoS filtering against the home connection's public address. If packets leave the laptop but never reach the site's edge, bring timestamps, source and destination IPs, and the affected protocols to the ISP.
Test the service you actually need, not just ping. Try a TCP connection to the VPN or HTTPS port and make an HTTPS request to the site's address or hostname. A failed ping alone doesn't establish that the application is down, because ICMP may be treated differently.
Compare the results over home internet and the hotspot, including whether the TCP connection starts at all. That gives you something more specific to trace than a general connectivity failure.
Don't rule out the laptop yet. Check its local firewall and security software for outbound rules affecting the site's IP or the VPN application. Capture at the laptop to see whether ping and the application traffic are actually sent on the home connection.
Since direct IP tests also fail, DNS is less likely to explain this particular problem. If the hostname resolves to both IPv4 and IPv6 addresses, though, compare those paths separately before changing adapter settings.
Answers are reviewed before publication.
_g32+tracehook.9:
The firewall capture shows traceroute traffic but no ping traffic from the user's address. I'll check the laptop side as well.
_f28~parcelwhistle.3:
Also check where that firewall capture runs. Some firewall platforms can drop traffic before it appears in an interface capture, so their drop counters or logs may tell you more.