skip to content

A colleague says an IPv4 NAT is the network's firewall because outside hosts cannot reach internal ones; what is right and wrong about that claim?

level: middleimportance: must knowfreq 52%

answer

  1. no mapping, no delivery
  2. mapping and filtering are separate axes
  3. the most transparent filtering is permissive
  4. forwarding, mapping protocols and ALGs open paths
  5. the illusion of a barrier

basics

~20 s

Partly right: an IPv4 NAT drops unsolicited inbound packets only because no mapping matches them. That side effect is not policy: it inspects nothing, forwarding rules and inside-initiated mappings open paths in, and inside-out threats pass untouched.

solid answer

~50 s

The blocking is real but accidental. A NAPT keeps a mapping table, and an inbound packet that matches no mapping has nowhere to be translated to, so it is dropped (for TCP, RFC 5382 REQ-4 has the NAT wait at least 6 seconds, then send ICMP Port Unreachable or drop silently). What gets back in once a mapping exists is decided by the NAT's *filtering behaviour* (RFC 4787), not by translation: with Endpoint-Independent Filtering, which REQ-8 recommends when application transparency matters most, any external host can reach `X:x` once the inside host has sent one packet out. Forwarding rules, NAT-PMP/PCP requests and ALGs add inbound paths without judging whether the exposure is safe, and a NAT inspects no payload and ignores attacks that start inside. RFC 2993 warns it can lower security by creating "the illusion of a security barrier". The real control is a stateful firewall with an explicit default-deny policy.

go deeper

for a junior

Remember that NAT blocks unsolicited inbound packets only because no mapping matches them, and that this is not the same as a firewall rule.

for a middle

Explain RFC 4787's split between mapping and filtering behaviour, and walk through the three filtering behaviours and what each lets back in.

for a senior

Show the holes in practice: forwarding rules, mapping protocols, ALGs and permissive filtering, plus inside-out threats a NAT never sees, and say what policy you would write instead.

for a principal

Frame the organisational risk: protection that exists only as a side effect is unaudited and disappears with IPv6, so make the default-deny an owned, reviewed policy.

## What the claim gets right A **NAPT** (Network Address and Port Translation, the "many hosts behind one address" form of NAT described in RFC 2663 and RFC 3022) keeps a **mapping table**: each entry ties an internal address and port `X:x` to an external address and port `Y:y`. An inbound packet addressed to `Y:y` is rewritten back to `X:x`. A packet that arrives at the public address and matches **no mapping** has nowhere to go, so it is dropped. That is why an unsolicited connection attempt from the internet usually fails, and why RFC 2993 lists "block inbound connections to all ports until they are administratively mapped" among the reasons NAT spread so quickly. For TCP, RFC 5382 REQ-4 even specifies the reaction to an unsolicited inbound SYN: do not respond for at least 6 seconds (the inside host may be attempting a simultaneous open), then send an ICMP Port Unreachable (Type 3, Code 3), or drop it silently if sending one would violate the NAT's security policy. ## Mapping is not filtering RFC 4787 separates two behaviours that the "NAT is a firewall" claim blurs: - **Mapping behaviour** decides when the NAT reuses the same `Y:y` for an `X:x`. REQ-1 requires **Endpoint-Independent Mapping**, and the RFC's security section says this "does not reduce the security of devices". - **Filtering behaviour** decides which external endpoints may send to `X:x` once the mapping exists. In RFC 4787's words, which packets are allowed "is determined by the external filtering behavior"; RFC 5382 says the same for TCP. | Filtering behaviour (RFC 4787) | After `X:x` sent to `Z:z`, who may send back to it | |---|---| | Endpoint-Independent Filtering | any external host, from any port | | Address-Dependent Filtering | only address `Z`, from any port | | Address and Port-Dependent Filtering | only exactly `Z:z` | REQ-8 recommends Endpoint-Independent Filtering when application transparency matters most and Address-Dependent Filtering when stricter filtering matters most. A NAT that follows the transparency recommendation lets the whole internet send to an inside host's mapped port as soon as that host has sent a single packet to anyone. ## Holes a NAT opens by design Inbound paths appear whenever someone asks for them, and none of these mechanisms judges whether the exposure is safe: 1. **Static translation** - Basic NAT's one-to-one address mapping (RFC 2663) or a port-forwarding rule translates every unsolicited packet for that address or port straight to the inside host. 2. **Mapping protocols** - NAT-PMP (RFC 6886), its successor PCP (RFC 6887) and the UPnP Forum's Internet Gateway Device protocol (not an IETF standard) let inside software create inbound mappings itself. 3. **Application-level gateways** - an ALG reading an FTP or SIP control message opens a mapping for the data or media connection that the payload names. 4. **Inside-initiated mappings** - under permissive filtering, any outbound packet opens a door that other hosts can use while the mapping lives. ## What a NAT never does - It inspects no payload and enforces no rule about **what** may be sent; a forwarded port exposes every flaw in the service behind it. - It does nothing about traffic an inside host **initiates**: a compromised machine calling out to an attacker's server gets a mapping like any other flow. - An edge NAT never sees traffic between inside hosts, so lateral movement is untouched. - It records translation state, not policy decisions, so there is no audit trail of what was allowed and why. RFC 2993's security section puts it bluntly: NAT "has the potential to lower overall security because it creates the illusion of a security barrier, but does so without the managed intent of a firewall", and it encourages the assumption that every threat is external. ## Why the distinction matters IPv6 deliberately has no NAT in its architecture, and RFC 6296 says that its prefix translator offers none of the security benefit NAPT44 might, "necessitating the use of a firewall". An organisation that relied on NAT's side effect discovers, the day it enables IPv6, that its inbound protection was never written down as policy. The durable answer is a **stateful firewall** with an explicit default-deny inbound rule, reviewed exceptions for published services and outbound rules where the risk warrants them - with or without translation beside it. ## How to answer it Concede the true part in one sentence (no mapping, no delivery), then separate mapping from filtering, list the holes, and name the real control. That order shows you understand why the misconception is so persuasive rather than just repeating that it is wrong.

  • Which filtering behaviour does RFC 4787 recommend, and why is that not simply the strictest one?
    REQ-8 recommends Endpoint-Independent Filtering when application transparency matters most and Address-Dependent Filtering when stricter filtering matters most. The strictest, Address and Port-Dependent Filtering, still complies but breaks applications that receive traffic from several peers or use rendezvous techniques, often forcing a relay. The recommendation trades filtering strength for working applications, which is exactly why a NAT's filtering should not be mistaken for security policy.
  • If a NAT already drops unsolicited inbound packets, what does a stateful firewall behind it add?
    Explicit policy: a default-deny that does not depend on mapping state, reviewed exceptions for each forwarded service, outbound rules that can stop a compromised host calling out, filtering between internal segments, and logs of what was allowed and denied. It also keeps working unchanged if the translation disappears, as it does when IPv6 is enabled.

A NAT is like a switchboard that only connects an incoming call to an extension that recently called out: nobody checks who is calling, and at its most permissive setting, once an extension has dialled anyone, any caller can ring it back.

saying these in an interview costs you the question

  • NAT hides internal addresses, so internal hosts are safe from the internet.
  • A forwarded port is protected because traffic still passes through the NAT.
  • NAT inspects packets and drops malicious ones.
  • NAT stops a compromised internal host from connecting out to an attacker.
  • Endpoint-Independent Mapping makes a NAT less secure.
  • IPv6 needs NAT to be as safe as IPv4.