A PC can reach its gateway but not a server in another subnet. What do you check?
Show the answer
Say this first
Since the gateway answers, the PC's link, VLAN and local addressing work. Next I check the PC's mask and gateway (a wrong mask can make the server look local), the route to the server's subnet on the gateway, the route back from the server side to the PC's subnet, ACLs and firewalls on the way, NAT, and the server's own gateway and firewall. Traceroute from the PC shows where it stops, and a ping from the gateway sourced from the PC's subnet tests the return path.
Go deeper
Order of checks
- PC settings.
ipconfig /all: mask and gateway. A /16 typed instead of a /24 makes the PC ARP for the server directly instead of sending to the gateway. - Forward route.
show ip route 10.30.0.15on the gateway. Missing, or the wrong next hop? - Traceroute from the PC. The last hop that answers is where to look next.
- Return route.
ping 10.30.0.15 source Vlan10on the gateway. If a plain ping works and the sourced one fails, the far side has no route back to the PC's subnet. - Filters. ACLs on the SVI and WAN interfaces (
show ip interface Vlan10 | include access list), firewall policies and NAT rules. - Server side. Its gateway, its host firewall, and on multi-homed servers, which NIC replies leave from.
A classic
A new subnet works locally, but nobody added it to the routing protocol or the firewall. Traffic leaves on the default route, and the far side has no route back.
They will ask next
How does a wrong subnet mask on the PC break remote access?
The PC uses its mask to decide what is local. With a mask that is too wide, it believes the server is on its own subnet and sends ARP requests for it instead of using the gateway. Nothing answers, unless proxy ARP on the router hides the mistake.
Traps
- Testing only the forward route. Missing return routes are just as common.