NAT vs Routing: What Happens When Traffic Leaves Your LAN

A router can route without NAT, and NAT can happen only at a boundary where addresses are rewritten. Home networks blend the two so tightly that many people call everything NAT.

That confusion matters when you build VLANs, VPNs, port forwards, site-to-site tunnels, or a homelab behind a firewall.

Quick reference: Routing forwards packets between networks. NAT changes addresses. Firewall policy decides whether traffic is allowed.

Interactive quick reference

NAT vs Routing: What Happens When Traffic Leaves Your LAN

Use this card as the simple mental model, then use the article sections below for the operational details.

Start simpleVerify the result

1. Route lookup

The device or router decides the next hop based on the destination network.

2. Policy check

Firewall rules decide whether the flow is allowed.

3. NAT translation

At the internet edge, the router rewrites private source addresses to a public address.

4. Return traffic

The NAT table maps replies back to the original internal device.

Start Here: The Beginner Foundation

Routing answers where a packet should go next. A host decides whether a destination is on-link or should go to a gateway, and a router looks for the most specific matching destination prefix in its forwarding information. It then sends the packet toward the selected next hop or interface. Normal IP forwarding changes hop-related fields and the link-layer envelope at each router, but it does not need to replace the packet's source and destination IP addresses.

Network address translation changes address information as traffic crosses a translation boundary. Basic NAT maps one address to another, while the NAPT common in IPv4 home networks also translates transport identifiers such as TCP or UDP ports so many internal clients can share one external address. The translator keeps mappings so replies can be rewritten back to the original client. Unsolicited inbound traffic normally needs a static mapping, port-forward rule, protocol-assisted mapping, or an existing state that matches the translator's behavior.

Firewall policy is a third decision: whether a flow is allowed. Consumer appliances often route, filter, and translate in one processing path, which makes the jobs look inseparable. They are not. Internal VLANs can be routed without NAT, a public or global address can still be protected by a stateful firewall, and a NAT mapping does not itself express the complete security policy. Troubleshoot by checking routes, policy, and translation separately in both directions.

The Fast Comparison

Concept	Question answered	Typical place	Common issue
Routing	Where should this packet go?	Routers, L3 switches, hosts	Missing route or wrong gateway
NAT	Which address should this packet appear from?	Internet edge, some VPN designs	Broken port forward or double NAT
Firewall	Should this packet be allowed?	Router/firewall boundary	Allowed route but blocked policy

Advanced Notes and Design Boundaries

Routing and NAT can occur in the same gateway, but they answer different questions. Routing chooses a next hop from destination and policy information; NAT rewrites address or port information and maintains translation state. Firewall policy decides what is allowed. Keeping those tables conceptually separate makes double NAT, asymmetric routing, port forwarding, CGNAT, and IPv6 failures much easier to diagnose.

• IP route selection normally prefers the longest matching destination prefix before implementation-specific preference and metric rules choose among otherwise eligible routes.
• Traditional NAPT maps internal address and transport identifiers to external tuples; exact mapping, filtering, timeout, hairpinning, and port-preservation behavior varies by protocol and implementation.
• Translation requires header and checksum adjustments and becomes harder around fragments, embedded addresses, IPsec, and application protocols that require an ALG or NAT-aware traversal method.
• A valid forward route does not guarantee a working flow: return routing, reverse-path checks, asymmetric firewall state, policy routing, and NAT placement can independently break the reply.
• IPv6 generally supports end-to-end global addressing without IPv4-style NAPT, although standards for prefix translation and IPv6-to-IPv4 translation exist for specific designs.

Troubleshooting Workflow

Capture the packet's identity at each boundary before changing rules: source and destination addresses, ports, protocol, ingress interface, selected route, translation, state entry, and egress interface. A broad “Internet is broken” test hides whether the failure is DNS, routing, NAT state, firewall policy, return-path asymmetry, or the provider's upstream CGN.

1. Define the failing flow as source and destination addresses, protocol, ports or ICMP type, ingress interface, and expected egress interface.
2. Inspect the source host's on-link decision and route table, then confirm its selected gateway and source address using a route-get or equivalent command.
3. At each router, verify the longest-prefix route and next hop for the destination plus a viable return route toward the original source.
4. Check firewall policy and state on every boundary, including interface or zone direction, address family, protocol, ports, and any reverse-path validation.
5. Inspect NAT rules and live translations for the exact flow, confirming rule order, original and translated tuples, egress address, and port-forward destination.
6. Use synchronized packet captures on both sides of the suspected boundary to identify whether the packet was routed, dropped, translated incorrectly, or returned by a different path.

Evidence and Packet-Path Acceptance Test

This Quick Reference is documentation-backed. TechGeeks did not independently validate every consumer router, firewall, ISP CGN, IPv6 deployment, or application traversal method. The defensible evidence is a correlated route lookup, firewall/state decision, NAT translation where used, packet capture, and end-to-end application result from the actual path.

• Record client addressing, gateway, route table, WAN address, and whether the WAN address is public, private, or shared-address space.
• Start one known outbound flow and correlate LAN capture, route decision, firewall/state entry, NAT mapping, and WAN capture.
• Test return traffic and a second flow with the same addresses but a different port so stateful behavior is visible.
• From a genuinely external network, test an intended inbound service and prove that both firewall policy and every required translation allow only that destination.
• Repeat the path with IPv6 where available; document prefix delegation and firewall behavior rather than assuming IPv4 NAT concepts apply.

What a Translation or Route Does Not Prove

• Routing does not require NAT; private and public networks can be routed wherever the administrative routing domain permits them.
• NAT is not a substitute for an explicit firewall policy, even though a typical stateful edge appliance performs both.
• A route in the forward direction is not sufficient; the destination and intermediate devices also need a valid return path.
• Port forwarding does not make a service work by itself; upstream NAT, firewall rules, host listeners, host firewalls, and address stability still matter.

Exposure, Logging, and Rollback Boundaries

NAT is not a security policy, and globally addressed IPv6 is not the same as globally permitted traffic. Use explicit stateful firewall rules, restrict administration, remove obsolete forwards, and test from outside. Translation and firewall logs can associate users, addresses, ports, and times; protect and retain them according to household or organizational policy and applicable law.

Only test networks and services you own or are authorized to assess. Before changing WAN mode, routes, NAT, or IPv6 delegation, export the configuration and preserve local console access. Roll back the last rule or route first; factory resets and simultaneous DHCP, NAT, DNS, and firewall changes destroy the evidence needed to locate the original fault.

Real-World Use Cases

• Use routing between internal VLANs when each subnet is known.
• Use NAT mainly at internet or special boundary points.
• Use firewall rules for segmentation, not NAT as a security plan.
• Avoid NAT between internal networks unless there is a clear design reason.

Failure Patterns to Recognize

• VPN connects but cannot reach networks because routes are missing.
• Port forward points to the wrong host after DHCP changes.
• Double NAT hides the real edge.
• Internal NAT makes troubleshooting logs confusing.

Common Mistakes

• Using NAT as a substitute for firewall policy.
• Adding static routes on one side only.
• Port forwarding a service that should be behind a VPN.
• NATing traffic between every VLAN by habit.

Quick Checklist

• Check the client route table.
• Check the default gateway.
• Check firewall policy.
• Check NAT rules and translation logs.
• Test with traceroute and packet capture when needed.

Common Questions

Can a router work with NAT disabled?

Yes. Routers fundamentally forward between IP networks. Enterprise cores, internal VLAN gateways, provider networks, and many IPv6 edges route without traditional IPv4 NAPT. NAT is added where address realms or protocol transitions require translation. With NAT removed, ensure the upstream network has routes back to internal prefixes and that firewall policy still enforces the intended access.

Why does a VPN connect but carry no internal traffic?

The control session can succeed while data-plane routes or policy are wrong. Check which prefixes the client installed, overlapping local subnets, forwarding and return routes, tunnel selectors, firewall zones, and any NAT exemption. Capture one test flow at the tunnel and destination gateway; this separates missing route advertisement from policy or translation errors.

Why does double NAT complicate port forwarding?

Each translator owns a separate external-to-internal mapping. An inbound connection must be mapped through the outer translator to the inner router and again through the inner translator to the final host, with compatible firewall rules and stable addresses at both layers. Carrier-grade NAT may make the outer mapping unavailable to the subscriber.

Does NAT provide security because private addresses are hidden?

Address translation can make unsolicited inbound initiation inconvenient when no mapping exists, but hiding addresses is not a complete security policy. A firewall explicitly controls flows, states, zones, protocols, and logging. NAT can also be configured with static mappings that expose a host. Evaluate security from enforced policy and service exposure, not from address translation alone.

Protocol and ISP Status Recheck

Fact-checked July 15, 2026 against RFC 1812, RFC 1918, RFC 3022, RFC 4787, RFC 6888, NIST firewall guidance, and APNIC's operational NAT explanation. The RFCs are stable reference points; the volatile facts are the ISP's addressing policy and the router's current firmware behavior.

Before publication, recheck whether named ISPs use CGNAT, offer a public IPv4 address, delegate IPv6 prefixes, or filter inbound traffic. Confirm router menu names, NAT/firewall ordering, UPnP defaults, hairpin behavior, and configuration export/restore on current firmware. Do not publish a port-forwarding recipe until it is tested from an external network.

Related TechGeeks Reading

• OPNsense vs pfSense vs UniFi vs a Consumer Router
• Homelab VLAN Design: Simple Network Segmentation That Works
• Remote Access Without Opening Router Ports

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

A router purchase should follow a written interface, throughput, IPv6, VLAN, VPN, logging, support-life, and recovery requirement. Confirm that quoted throughput includes the firewall or VPN features you will enable and that configuration export works; extra ports or faster radios do not repair an ISP CGNAT limitation or an incorrect route.

• Amazon search: small business firewall router
• Amazon search: managed switch VLAN

References

• RFC 3022: Traditional IP Network Address Translator
• RFC 1918: Address Allocation for Private Internets
• RFC Editor: RFC 1812, Requirements for IP Version 4 Routers
• RFC Editor: RFC 3022, Traditional IP Network Address Translator
• RFC Editor: RFC 4787, NAT Behavioral Requirements for Unicast UDP
• RFC Editor: RFC 6888, Common Requirements for Carrier-Grade NATs
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• APNIC Blog: Basic Routing Concepts, NAT

The July 15, 2026 review validates the protocol distinctions, not an ISP's present CGNAT policy or a particular router's rule-processing behavior.