IP Routing and NAT: How Packets Cross Networks

Introduction

An IP packet starts with a destination address, but that address alone does not tell a host how to reach it. The host checks its routing table, chooses a next hop, and sends the packet toward that next hop. Routers repeat the same basic decision until the packet reaches its destination network.

At a network boundary, a router may also translate the packet’s address or port. That is Network Address Translation (NAT). Routing decides where a packet goes; NAT changes selected fields as it passes through a device. The two often appear together in home and enterprise networks, which is why their jobs are easy to blur.

This guide covers route selection, routing behavior, and common NAT patterns, then shows how to inspect paths and reason about failures such as asymmetric routing. It also compares the operational trade-offs of translation and routing choices.

When to Use

Routing tables are needed anywhere traffic must move between IP networks. A default gateway is useful for end hosts that have one ordinary path off their local subnet. More specific static routes fit small networks with stable topology, while dynamic routing helps routers adapt in larger or changing networks.

NAPT is commonly used when many private IPv4 devices need outbound access through a smaller number of public addresses. Static NAT or a port forward can expose a specific service when an inbound connection is required. In either case, pair the translation rule with explicit firewall policy and document which internal system receives the traffic.

When NOT to Use

Avoid adding NAT between networks when you can route the address space directly and both sides can use unique, reachable addresses. Translation makes packet traces and logs harder to interpret, and protocols or applications that embed IP addresses may need extra handling.

Do not create broad port forwards just to make a service reachable. Expose only the required destination and port, restrict source networks when practical, and protect the service itself. NAT does not fix overlapping address plans cleanly; renumbering or a deliberate routing design is usually easier to operate.

Production Failure Scenarios

A more specific route sends traffic the wrong way

A host has a default gateway and a stale /25 route for a destination that should follow the default. Because the /25 prefix is more specific, longest-prefix match selects it. Check ip route get <destination> on the source and inspect routes on each router along the path before changing NAT rules.

The return path differs from the outbound path

Traffic leaves through one edge router, but the reply returns through another device that has no matching translation state. The connection stalls even though outbound packets appear to leave successfully. Compare both directions of a packet capture and verify routing symmetry or configure the network and translation design to support asymmetric paths.

A port forward reaches the wrong host

An internal address changed after a DHCP lease or deployment, but the edge mapping still points to the previous host. Keep internal service addresses stable through reservations or static assignment, and verify the forward target after network changes.

Traceroute appears to stop early

The last visible hop may filter ICMP time-exceeded messages. Test the destination service directly, check firewall counters, and compare with another path measurement before declaring a routing failure. Traceroute reports responses to its probes, not a full inventory of routers.

Translation state exhausts or expires

A large number of short-lived connections or a long idle period can leave an application without a usable mapping. Inspect the translation table and its timeout behavior on the relevant device. If the service needs long idle sessions, tune timeouts deliberately and confirm that intermediate firewalls agree.

Trade-Off Table

Observability Checklist

• Use ip route to inspect installed routes and ip route get <destination> to verify the host’s actual next-hop choice.
• Run traceroute -n <destination> or traceroute -6 -n <destination> to compare the IPv4 or IPv6 path; treat silent hops cautiously.
• Capture traffic on both sides of the translation device and compare source/destination address and port tuples.
• Check NAT or connection-tracking counters for new mappings, established flows, drops, and table pressure.
• Review firewall logs separately from translation logs. A successful NAT mapping does not prove a firewall permitted the intended traffic.
• Monitor route changes and interface state so a path change can be correlated with packet loss or asymmetric return traffic.

Security and Compliance Notes

Treat a port forward as a deliberate service exposure. Restrict its destination and port, limit who can connect where possible, and keep host-level controls in place. Review both IPv4 and IPv6 policy: NAT is common in IPv4 deployments, but IPv6 connectivity often uses globally routable addresses and still needs firewall rules.

Logs should preserve enough information to correlate a translated public flow with its private source, including timestamp, protocol, address, and port mapping. Retain that data only as long as operational and compliance requirements call for it, and protect it because connection metadata can reveal user activity. Follow your organization’s policy for access, retention, and incident response.

Common Pitfalls / Anti-Patterns

• Assuming a default route wins over every other route. A matching, more specific prefix takes precedence.
• Blaming NAT when a host has selected the wrong gateway or a router lacks a return route.
• Treating a successful outbound connection as proof that unsolicited inbound traffic is safely filtered.
• Building a chain of translations without documenting which device owns each mapping.
• Forgetting that a NAT mapping is stateful and that a different return path may reach a device without the required state.
• Reading traceroute’s unanswered hop as proof that the router cannot forward traffic.
• Assuming NAT removes the need for unique internal addressing. Overlapping networks still cause routing ambiguity.

Quick Recap Checklist

• A router uses a routing table to choose a next hop for a destination.
• Longest-prefix match selects the most specific matching route; a default route covers destinations without a more specific match.
• The IPv4 TTL and IPv6 Hop Limit decrease at each forwarding hop to prevent endless loops.
• NAT rewrites IP addresses; NAPT/PAT also rewrites transport ports so flows can share an address.
• Stateful translation maps replies to existing flows; inbound connections need an explicit mapping or another supported design.
• NAT and firewall filtering are separate functions. Configure and monitor both.

Interview Questions

Further Reading

• RFC 1812: Requirements for IPv4 Routers
• RFC 3022: Traditional IP Network Address Translator
• RFC 4632: Classless Inter-domain Routing (CIDR)
• TCP, IP, and UDP: How Transport and Network Layers Work Together
• Network Ports and Firewalls
• The OSI and TCP/IP Network Models

Conclusion

Routing tables determine a packet’s next hop, with longest-prefix match choosing the most specific route and a default gateway handling destinations without a closer match. NAT changes addresses at a network edge; NAPT/PAT also changes ports and tracks flows so replies can return to private hosts. Use routing tools and packet captures to follow each direction, and keep firewall policy separate from translation.