Trace the packet in the same order the network must process it
Packet-path questions become much easier when you stop thinking in device names and instead follow the forwarding decisions in sequence. The sender first decides whether the destination is local or remote. That decision determines the Layer 2 target. The frame must stay in the correct VLAN to reach the next hop. A router then performs a route lookup. Firewalls or ACLs may allow or deny the crossing. NAT may rewrite address information. Finally, the return path must work as well.
Once you can follow the ordinary request and reply, extend that sketch with the AP Networking NAT and PAT Troubleshooting Practice Test. Its three difficulty sets add inside/outside mappings and multiple translation boundaries, so you can test whether the returning packet still has a usable state and forwarding path.
Same-subnet traffic is switched locally and does not use the default gateway for ordinary forwarding
Suppose 10.1.10.25/24 sends to 10.1.10.80. Both addresses are inside 10.1.10.0/24, so the sender treats the destination as local. It resolves the destination host's MAC address and sends the frame directly into the local VLAN.
The strongest answer should explicitly separate the IP destination from the Layer 2 forwarding target.
Remote traffic keeps the server's IP destination but uses the gateway's MAC on the first Ethernet segment
Now 10.1.10.25/24 sends to 10.2.20.40. The destination is outside the local /24, so the sender forwards to its default gateway. The frame is addressed to the gateway MAC, while the IP packet still targets 10.2.20.40.
Routers remove and rebuild Layer 2 framing at each routed hop
The IP source and destination are generally carried end-to-end across routed hops unless NAT changes them. The Ethernet source and destination MAC addresses are local to each Layer 2 segment and are rebuilt as the packet moves through routers.
| Field | First LAN | After router |
|---|---|---|
| Source IP | 10.1.10.25 | Usually still 10.1.10.25 unless NAT applies |
| Destination IP | 10.2.20.40 | Still 10.2.20.40 |
| Source MAC | Client MAC | Router egress MAC |
| Destination MAC | Gateway MAC | Next-hop or server MAC |
Swipe horizontally to see the field comparison.
The correct route is useless if the packet never reaches the Layer 3 boundary
A client on VLAN 10 may need to cross a trunk to reach its default gateway. If VLAN 10 is omitted from the trunk, the frame cannot reach the gateway even if the gateway's route table is perfect.
Endpoint placement and inter-switch carriage are two different Layer 2 checkpoints
Access port
Places an endpoint into one intended VLAN.
Trunk
Carries multiple VLANs between infrastructure devices.
Failure clue
Wrong access VLAN affects endpoint placement; missing trunk VLAN affects carriage between devices.
After the gateway receives a remote packet, routing chooses the next forwarding path
Routers compare the destination IP against the routing table and select the most specific matching prefix. A default route is used only when no more-specific route matches.
A working default route does not prove the internal server route is correct
A client can browse the Internet because the default route works while internal server traffic fails because a more-specific internal route is missing or wrong. The correct troubleshooting question is not “Does the router have a route?” but “Which route actually wins for this destination?”
Routing tells the packet where to go; firewall policy decides whether it may cross
Suppose routing correctly delivers Staff-to-Server traffic to the firewall. The firewall can still deny TCP/443. Conversely, a firewall rule can permit TCP/443 while a missing route prevents the packet from reaching the policy boundary.
Successful ICMP does not prove the application port is reachable
If ping succeeds but HTTPS fails, the basic IP path works for ICMP. The stronger next branches are TCP/443 policy, service listening state, host firewall, or application health.
NAT changes address information only after the packet reaches the translating device
For Internet-bound traffic, a router may translate a private source address to a public one. But NAT cannot repair a broken access VLAN, missing gateway, or wrong internal route. The packet must first reach the NAT boundary.
End-to-end success requires the response to find its way back
A forward packet can arrive at the server while the reply fails because the server-side router lacks a route back to the client subnet. Stateful firewalls and NAT can make the return direction even more important because the response may need to traverse the same stateful device.
Different forward and return paths can break stateful policy even when both directions have routes
Asymmetric routing is not automatically invalid, but a stateful firewall may see the SYN in one direction and never see the returning SYN-ACK if the response takes another path. That device can then drop traffic because the session state is incomplete.
When the server sees the request and sends a response but the client never receives it, trace the return direction explicitly.
Capture location tells you which part of the path is already proven
| Capture result | Strong inference |
|---|---|
| Client sends SYN, nothing returns | Failure is somewhere after client transmit |
| Firewall ingress sees SYN, egress does not | Policy/NAT/routing at firewall becomes stronger |
| Server never sees SYN | Failure is before server |
| Server sees SYN, sends SYN-ACK | Forward path + service response work |
| Client never sees SYN-ACK | Return path/stateful device becomes stronger |
Swipe horizontally to see the packet-capture table.
Change one fact and watch the expected path change
Use this simulator to practice the first packet-path decisions. It intentionally keeps the network small so you can focus on the evidence chain.
10.1.10.25/24 → 10.1.10.80
Decision: local destination. The sender resolves 10.1.10.80 directly, frames to the destination MAC, and switches within the VLAN.
Falsifying observation: if the client is actually configured with a /27 that places the server outside its local prefix, then the “same-subnet” interpretation is no longer correct.
10.1.10.25/24 → 10.2.20.40
Decision: remote destination. The sender resolves the gateway MAC and keeps 10.2.20.40 as the IP destination.
VLAN 10 is missing from the trunk to the gateway
The client is correctly assigned to VLAN 10, but the trunk carrying traffic toward the Layer 3 gateway does not allow VLAN 10.
Inference: routing has not yet failed because the frame never reaches the router. Inspect trunk VLAN allowance, tagging, and native-VLAN assumptions before editing routes.
Routing is correct but firewall denies TCP/443
The firewall receives the packet on the expected interface and the route table points toward the server subnet. The security policy denies the flow.
Inference: path selection is working to the policy boundary; the failing dependency is permission. Verify whether the requirement actually calls for TCP/443 to be allowed from this source segment.
Server receives the request but the return route is missing
The server-side capture shows the client's SYN arrive. The server generates a response, but its gateway lacks a route back to the client subnet.
Inference: forward routing, VLAN carriage, and firewall permission are known-good enough to focus on the return path.
Each checkpoint should reduce the possible failure set
| Observed evidence | Supports | Still unproven |
|---|---|---|
| Gateway ARP resolves | Local next-hop resolution | Route/policy/server |
| Gateway ping works | Client-to-gateway path | Remote route and application |
| Router has route | Forwarding decision exists | Firewall permission |
| Firewall allows flow | Policy permits traffic | Server listener/return path |
| Server sees SYN | Forward path reaches server | Reply delivery |
| Client sees SYN-ACK | Return path works for TCP handshake | Application-layer success |
Swipe horizontally to see the evidence matrix.
Mastery comes from knowing which single fact changes the path decision
Start with a scenario, then alter one fact. Change the prefix from /24 to /27. Remove one VLAN from the trunk. Replace an allow rule with a deny. Delete the return route. Each modification should move the failure boundary in a predictable way.
Reject answers that occur after the first demonstrated failure
If VLAN 10 is missing from the trunk, changing the remote server application cannot fix the path because the packet never reaches routing. If the server sees the request and sends a reply, blaming the client's ARP resolution is weak because the forward path already succeeded.
A strong answer explains both the success and the failure evidence with the fewest unsupported assumptions.
Trace 10.10.10.25 → 10.20.20.40 in both directions
Now remove one return route. Predict which observations still succeed: client ARP can still work, gateway ping can still work, the forward packet may still reach the server, and the server may even transmit a reply. The session fails only when the response cannot complete the return path.
Keep Layer 2, Layer 3, policy, and service evidence separate
- Remote traffic uses the gateway MAC, not the remote server MAC, on the first Ethernet segment.
- A valid route does not guarantee firewall permission.
- A firewall allow rule does not repair a missing route.
- A missing trunk VLAN breaks the path before routing.
- Successful ping does not prove TCP/443 is open.
- A forward packet arriving does not prove the return path works.
- NAT can rewrite addresses but does not replace routing.
Verify the repaired path and preserve known-good controls
After the targeted correction, repeat the original failed test. Then repeat one known-good comparison and one intentionally blocked control. This catches accidental overcorrection.
Original: intended client reaches intended server.
Known-good: previously working path still works.
Negative control: prohibited source or port remains blocked.
Evidence: save the route, firewall log, capture, or table entry that directly proves the corrected boundary.
24 Packet Path digital flashcards
Practice local-vs.-remote decisions, ARP targets, MAC rewrites, access VLANs, trunks, longest-prefix routing, firewall policy, NAT, return routes, packet capture, evidence boundaries, and verification.