Working Internet access narrows the problem, but it does not prove the internal path
A client that can browse the Internet but cannot reach a local server already gives you valuable evidence. The client has usable IP configuration, a working path to at least one gateway, and some functioning external connectivity. The mistake is to treat that success as proof that internal routing, VLAN membership, internal DNS, server firewall policy, or the server application are also correct.
Preserve the known-good evidence instead of restarting from zero
If the client reaches an external IP, you can usually preserve the local client stack, basic gateway reachability, and at least one functioning outbound path as known-good. That does not mean every route or every firewall rule is correct. It means the troubleshooting focus should move toward the first dependency that differs between the Internet destination and the internal server.
Likely known-good
Client interface, usable IP settings, some gateway path, some external routing.
Still unknown
Internal route, VLAN placement, internal DNS, internal firewall/ACL, server state.
Best method
Compare working external path with failing internal path and test the first point of divergence.
If client and server are local peers, routing is not the first dependency
Suppose the client is 10.10.20.25/24 and the server is 10.10.20.80/24. Both addresses are in the same subnet, so the client should resolve the server's MAC address directly and send the frame locally. The default gateway is not required for ordinary same-subnet communication.
If this path fails while Internet access works, inspect ARP, switch forwarding, VLAN membership, local host firewall, and the server service before blaming the default route.
If the server is in another VLAN or subnet, the path becomes routed and policy-controlled
Now suppose the client is 10.10.20.25/24 and the server is 10.10.40.80/24. The client sends the packet to its default gateway. The router or multilayer switch must have a valid route to 10.10.40.0/24, and any firewall or ACL between the segments must permit the required flow.
A client can reach the Internet and still misclassify the local server
A wrong prefix can alter the local-versus-remote decision. For example, a client that belongs in 10.10.20.64/27 but is configured /24 may believe a server at 10.10.20.100 is local even when it should be routed. The client then ARPs for the server instead of sending to the gateway.
Resolve the hostname before assuming the server path is correct
Organizations often use internal DNS so that a name such as files.example.local or even a public-style hostname returns an internal address for internal clients. If that record is wrong, the client may follow a completely different path than expected.
That wrong answer can cause hairpin NAT, firewall denial, or a path to an external address that is not intended for inside users.
Numeric IP testing separates name resolution from transport reachability
If the hostname fails, test the known internal IP directly. If the IP works but the hostname fails, DNS becomes much stronger. If both fail, DNS may still be wrong, but it is not the only problem.
| Test | Result | Strong inference |
|---|---|---|
| Hostname fails, IP works | Transport path works | DNS/name-resolution problem likely |
| Hostname fails, IP fails | Path/service unresolved | Continue routing/firewall/server checks |
| Hostname works, IP works | Both paths healthy | Original problem likely fixed |
Swipe horizontally to see the test matrix.
A working Internet default route does not guarantee the internal route table is correct
A router can successfully forward 0.0.0.0/0 toward the ISP while lacking a route to an internal server subnet. It can also contain a wrong more-specific route that overrides the default path for that internal destination.
Always inspect the exact server prefix. Route selection is based on the most specific matching route, not on the fact that “the Internet works.”
Compare the failing client's routing context with a known-good client
If one client role can reach the server and another cannot, compare source subnet, gateway, route table, VPN state, and policy. If every client in one VLAN fails but clients in another VLAN succeed, the shared internal route or policy for that source segment becomes stronger.
This scope comparison is often more useful than repeating generic pings.
Internal firewall rules often differ by source network, role, port, or application
A server may intentionally allow Staff but deny Guests. A network firewall may allow TCP/443 but deny TCP/22. A host firewall may permit connections from the server VLAN but not from a newly added client VLAN.
| Source | Destination | Port | Expected |
|---|---|---|---|
| Staff | App server | 443 | ALLOW |
| Guest | App server | 443 | DENY |
| Admin | App server | 22 | ALLOW |
| Student | App server | 22 | DENY |
Swipe horizontally to see the policy table.
If ping works but the application port fails, basic IP reachability is no longer the first suspect
Suppose the client can ping the server but HTTPS fails. That means packets can reach the server and replies can return for ICMP. Now inspect TCP/443 filtering, whether the service is listening, whether the service is bound to the expected interface, and whether host firewall policy allows the client subnet.
A reachable host can still have a stopped or misbound application
A web server may be down while the operating system remains reachable. The service may also be listening only on 127.0.0.1, which allows local tests on the server but denies remote clients because the process is not bound to the LAN interface.
Check the actual listener and server logs before rebooting unrelated clients.
Server-side filtering can block one client subnet while allowing others
Host firewalls often apply rules by interface profile, source subnet, protocol, or port. A new client VLAN can be routed correctly all the way to the server and still fail because the server firewall does not include that source subnet.
Compare the policy for a known-good source with the failing source. That keeps the diagnosis tied to observed scope.
The server side must know how to send the reply back to the client subnet
A newly created client VLAN may have a forward route into the server network while the server-side router lacks a route back. Packet capture on the server can show the request arriving, but no successful reply path exists toward the client.
This is why return-path analysis matters even when the request clearly reaches the server.
Different forward and return paths can break stateful security even when both routes exist
Asymmetric routing is not automatically wrong, but stateful firewalls and NAT devices often expect to see both directions of a flow. If the request crosses one firewall and the reply bypasses it, the firewall may never see the expected state transition.
When packets arrive at the server but replies never complete the connection, inspect both directions rather than assuming the forward route is enough.
A client can have Internet access while still being attached to the wrong internal trust zone
A wireless client may join an SSID that maps to a guest VLAN with Internet access but no internal-server reachability. A wired port may be assigned to the wrong access VLAN. The symptom can look like “Internet works, local server does not” even though the network is enforcing policy exactly as configured.
Compare a working client from the same role before changing infrastructure
If another Staff client on the same VLAN reaches the server, compare IP/prefix, gateway, DNS answer, route/VPN state, and endpoint firewall. If every Staff client fails while Admin clients work, the issue is more likely shared policy or routing for Staff.
The comparison tells you whether the fault belongs to one endpoint or an entire source segment.
Client-side capture shows whether the request leaves and whether anything comes back
This proves the client is attempting the connection. The missing reply could still be routing, firewall, server listening state, or return path.
Server-side capture separates path failure from server response failure
If the server never sees the client's SYN, the failure is upstream: VLAN, route, ACL/firewall, or path selection. If the server sees the SYN but sends no SYN-ACK, inspect the listener and host firewall. If the server sends a SYN-ACK but the client never sees it, inspect the return path and stateful policy.
| Server capture | Stronger branch |
|---|---|
| No request arrives | Network path / firewall before server |
| Request arrives, no reply leaves | Service / host firewall / bind |
| Reply leaves, client never sees it | Return route / stateful device / asymmetric path |
Swipe horizontally to see the packet-capture matrix.
Internet works, hostname fails, server IP works
The client browses external sites, cannot open intranet.example.com, but can open https://10.10.40.80.
Inference: routing and the application path are working by IP. Internal DNS answer, search suffix, or split-DNS behavior is the stronger branch.
Internet works, server IP fails, same-subnet peer can reach server
Another client on the same Staff VLAN reaches the server successfully.
Inference: server and shared inter-VLAN path are likely healthy enough to compare the failing client's IP/prefix, local firewall, VPN state, DNS answer, and endpoint-specific routes.
Guest Internet works but internal server is blocked
The guest client receives the expected guest subnet, browses the Internet, but cannot reach the payroll server. Staff clients can.
Inference: this may be intentional security policy, not a fault. Verify the requirement before changing the firewall.
Ping works but TCP/443 fails
The server responds to ICMP from the client subnet, but HTTPS never opens.
Inference: basic routing and return path for ICMP work. Investigate TCP/443 policy, listener state, bind address, or application health.
Server sees the request but reply takes the wrong route
A packet capture shows SYN arriving from 10.10.20.25. The server sends a SYN-ACK to its gateway, but the return router chooses a different path that bypasses the stateful firewall.
Inference: fix routing symmetry or firewall state handling rather than changing client DNS.
Each successful test should shrink the problem space
| Evidence | What it supports | What remains unknown |
|---|---|---|
| Internet works | Some gateway/upstream path works | Internal route/policy/service |
| Server IP works | Path + service by IP | DNS correctness |
| Server ping works | ICMP reachability | Application port/service |
| Server sees SYN | Forward path reaches server | Listener/host firewall/return path |
| Server sends SYN-ACK | Server responded | Return path/stateful policy |
Swipe horizontally to see the evidence matrix.
Use the first differing dependency between Internet and internal-server paths
Do not let the working Internet path mislead you
- Working Internet does not prove internal DNS is correct.
- Working default route does not prove the server subnet route exists.
- Different VLANs do not guarantee policy allows the flow.
- Successful ping does not prove the application port is open.
- Server reachability does not prove the service is bound to the correct interface.
- Forward-path success does not prove the return route is correct.
- Guest inability to reach a trusted server may be intentional security policy.
Retest the full requirement after the repair
After fixing the issue, test the server by internal IP, then by hostname, then the actual application and authorization path. Confirm the intended client role can connect. Finally, confirm Internet access still works and that the change did not accidentally open access for a role that should remain blocked.
Positive: intended client reaches the local server by name and IP.
Negative: prohibited client roles remain blocked.
Regression: Internet access remains normal.
24 Internet-Works / Local-Server-Fails digital flashcards
Practice path comparison, same-vs.-different subnet logic, internal DNS, route selection, firewall policy, server listening state, VLAN placement, packet capture, return routes, and verification.