What is NAT hairpinning, and why does an inside host need it to reach a port-forwarded server by the network's public address?
answer
- the packet must turn around
- the public address is the NAT's own
- relay inside to inside
- RFC 4787 Section 6
basics
~20 sHairpinning is a NAT relaying a packet from one inside host back inside to another host that was addressed by its public, translated endpoint. Without it, an inside client that resolves a service name to the public address cannot reach the server.
solid answer
~50 s**Hairpinning** (also called NAT loopback or NAT reflection) is a NAT receiving, on its inside interface, a packet addressed to one of its own outside endpoints that maps to an inside host, translating it and sending it back inside. RFC 4787 defines it, and RFC 4787 REQ-9 (UDP) and RFC 5382 REQ-8 (TCP) say a NAT MUST support it; RFC 5508 REQ-7 adds ICMP requirements. An inside host needs it because public names and endpoints point at the public address: DNS returns `203.0.113.10` for the portal everywhere, a laptop roams between home and office, and peers behind one NAT learn each other's public endpoints from a rendezvous server. Many devices still do not hairpin, because their forward rule matches only outside traffic, so the fixes are enabling it, split-horizon DNS, or using the inside address.
go deeper
Recall the picture: the inside packet goes to the NAT's public address and must be turned around and sent back inside to the server; without that, the public name fails from inside.
Explain who sends what where: the client follows DNS to the public address, the packet reaches the NAT on its inside interface, and the NAT must apply the forward and relay it back.
Show you know it is a MUST in RFC 4787 and RFC 5382 yet often missing, and name the deployments that hit it: published services, roaming laptops, peers behind one NAT, subscribers of one carrier-grade NAT.
Weigh whether to depend on hairpinning at all, given patchy support, against keeping inside clients off public addresses with split-horizon DNS or moving services to IPv6.
## The situation hairpinning solves A small company runs a web portal on an inside server, `10.20.0.10`, port `443`. Its IPv4 NAT owns one public address, `203.0.113.10`, and a **port forward** maps `203.0.113.10:443` to `10.20.0.10:443`. Public DNS answers `portal.example.com` with `203.0.113.10`, so customers on the Internet reach the portal through the forward. Now an employee at `10.20.0.55`, on the same inside network, types the same name. Their resolver returns the same public answer, `203.0.113.10`. That address is not on the employee's subnet, so the packet goes to the default gateway, which is the NAT itself. The NAT now holds a packet that: - arrived on its **inside** interface, - is addressed to one of its own **outside** addresses and ports, - and should end up at another **inside** host. Delivering it means turning the packet around and sending it back the way it came, which is why the behaviour is called **hairpinning** (the industry also says **NAT loopback** or **NAT reflection**). ## The definition in the specifications RFC 4787 (the UDP behavioural requirements, BCP 127) defines it in Section 6: when two hosts X1 and X2 sit behind the same NAT and X2 has an external endpoint `X2':x2'`, traffic from X1 to `X2':x2'` "goes to the NAT, which must relay the traffic from X1 to X2". The point is that the two inside endpoints can communicate "even if they only use each other's external IP addresses and ports". | Specification | Requirement | Scope | |---|---|---| | RFC 4787 | REQ-9: a NAT MUST support hairpinning | UDP | | RFC 5382 | REQ-8: a NAT MUST support hairpinning for TCP | TCP | | RFC 5508 | REQ-7: hairpinned ICMP Query sessions (Basic NAT) and ICMP Error messages (all NATs) | ICMP | | RFC 6888 | REQ-1: a carrier-grade NAT MUST meet the behavioural requirements of each transport it forwards | CGN | | RFC 6296 | Section 4.3: NPTv6 translators MUST support hairpinning | IPv6 prefix translation | The UDP and TCP documents also say which source address the relayed packet must carry; that detail, and the reason the NAT has to rewrite more than the destination, is the mechanism behind the definition. ## Where an inside host meets it 1. **A published service used from inside.** The name resolves to the public address everywhere, so an inside client follows the public path. 2. **A roaming device.** A laptop configured with one name or address works at home and fails in the office, or the reverse. 3. **Peers that learned public endpoints.** Two applications behind the same NAT register with a rendezvous server, receive each other's public endpoints and try them. RFC 5128 notes that they can talk this way only if the NAT relays inside-to-inside sessions. 4. **Subscribers of the same carrier-grade NAT.** Two customers behind one provider's large NAT meet through public endpoints that both map to the same translator, so the provider's NAT must hairpin. ## Why so many devices fail The requirement is a MUST, yet real devices often lack it. RFC 5128 (Informational, 2008) reports that fewer than 25% of the NAT devices in the tests it cites passed the hairpinning checks. The usual implementation reason is simple: a port-forward rule is matched only against packets arriving on the **outside** interface. A packet from inside never matches it, so the device treats it as a packet for its own address. What the client sees depends on the device: - the router's own service on that port answers, such as its management page; - the router refuses or drops it, and the connection fails or hangs; - the router rewrites only the destination, and the connection hangs because the server's reply never returns through the NAT. ## The usual ways around it - **Turn hairpinning on**, where the device offers it, so the NAT relays inside traffic correctly. - **Split-horizon DNS**: the inside resolver answers the same name with `10.20.0.10`, so inside clients never use the public address. - **Use the inside address or an inside-only name** directly, which works but breaks the "one name everywhere" model. Under plain IPv6 the problem disappears: there is no NAT in IPv6's architecture, so a server's global address is the same inside and out, and inside traffic is routed straight to it.
- Do two subscribers behind the same carrier-grade NAT need hairpinning to reach each other's public endpoints?Yes. Both public endpoints belong to the same translator, so traffic between them arrives on its inside and must be relayed back inside. RFC 6888 REQ-1 makes a carrier-grade NAT meet the UDP, TCP and ICMP behavioural requirements, which include hairpinning, and RFC 5128 notes that hosts behind different second-level NATs under one first-level NAT cannot reach each other by hole punching unless that first-level NAT hairpins.
- Does an IPv6 network need hairpinning to reach its own servers by their global addresses?Not with ordinary global addressing. IPv6's architecture has no NAT, so a server's global address is the same inside and outside, and inside traffic is routed straight to it; a firewall may filter but does not translate. The exception is a site using NPTv6 prefix translation (RFC 6296, Experimental), whose Section 4.3 requires the translator to support hairpinning.
Calling your company's public switchboard number from a desk phone in the same building: a good switchboard notices the call came from inside and connects it back to the right desk, while one that only routes outside calls inward leaves you with a dead line.
saying these in an interview costs you the question
- Hairpinning is a routing loop that a correctly configured router prevents.
- If a port forward works from outside, it automatically works from inside as well.
- Hairpinning is optional in the NAT behavioural requirements.
- Inside hosts can never use the public address; that is simply how NAT works.
- An IPv6 network with global addresses needs hairpinning just like IPv4 NAT.