What is Hairpin NAT (NAT Loopback)?

Hairpin NAT, also called NAT loopback or NAT reflection, is a router or firewall feature that allows a device on your local network to reach another device on that same network by using its public-facing IP address and port. The router recognises the connection, translates it back towards the internal server and keeps the exchange working. It matters when you host a website, NAS, camera interface, game service or another application that needs to use the same public hostname both at home and away.

The important distinction: ordinary port forwarding can make a service reachable from outside your network without making that same public address work from inside. Hairpin NAT is the additional behaviour that makes the inside-to-inside connection through the external mapping possible. It does not require your traffic to travel out to the ISP and back.

How does Hairpin NAT work?

Imagine a UK household with a router using the example public IPv4 address 203.0.113.10. A home server listens on 192.168.1.50:443, and a laptop uses 192.168.1.20. A port-forwarding rule directs traffic arriving at 203.0.113.10:443 to the internal server. The example public address belongs to a documentation-only range, not a real customer connection.

1. The laptop requests https://home.example using DNS. The name resolves to 203.0.113.10, the router's public-facing address in this example.

2. The laptop sends a TCP connection towards 203.0.113.10:443. The packet reaches its router from the LAN side.

3. The router matches its external address and port to the server's internal mapping and translates the destination to 192.168.1.50:443.

4. The router applies the required source translation or equivalent stateful handling so that return packets take the correct path through the router rather than bypassing the translation state.

5. The server replies. The router reverses the translations, and the laptop sees a valid connection to the public-facing endpoint it originally contacted.

The key is bidirectional consistency. Destination translation alone can fail when a server and client share a subnet: the server may reply directly to the laptop from its private address, while the laptop expects replies from the public address it contacted. Source translation on the hairpin path is one common solution. Exact implementation depends on the router and firewall.

The IETF defines this behaviour in RFC 4787, section 6 and requires hairpinning for NATs conforming to that document's UDP behaviour specification. That is not a guarantee that every home router or every TCP port-forwarding configuration supports it.

Hairpin NAT: visual explanation

The diagram below shows the internal laptop, public router address and private server address, then contrasts a failing internal connection with a working hairpin connection. It also illustrates split-horizon DNS as an alternative.

Hairpin NAT vs port forwarding

• Port forwarding: maps an inbound public IP address and port to a private IP address and port, primarily for connections arriving from outside the LAN.

• Hairpin NAT: allows an internal client to use that external mapping to reach an internal service. It is often dependent on a working port-forwarding rule.

• NAT reflection: another name for the hairpin behaviour, used by some firewall products.

• NAT traversal: the broader set of techniques for making connections work through one or more NAT devices. Hairpinning is only one possible behaviour.

For the underlying inbound rule, read What is Port Forwarding? The distinction is especially important when a port-forward works over mobile data but fails on home WiFi.

Why does a service work from outside but not inside?

Suppose your home server opens normally over mobile data, but the same hostname times out when your phone switches to home WiFi. External access has shown that at least one outside path works. The difference may be the router's handling of connections originating on its LAN and aimed at its own public address.

Missing hairpin support is one possible cause, but not the only one. DNS filtering, an IPv6 address returned instead of IPv4, host firewall rules, a reverse proxy, a different local VLAN, browser HTTPS enforcement, and a misconfigured server can produce similar symptoms. A reliable diagnosis tests each path separately.

Hairpin NAT and split-horizon DNS: which is better?

Split-horizon DNS, also called split-view DNS, returns different DNS answers depending on where the query originates. Inside your home network, home.example could resolve to 192.168.1.50. Outside, it could resolve to 203.0.113.10. Local clients then reach the server directly using its private address rather than asking the router to translate a public-address connection back into the LAN.

• Hairpin NAT preserves a single public hostname and usually needs no special client-side DNS configuration, but requires suitable router support and correct translation rules.

• Split-horizon DNS can avoid hairpin translation and is often easier to control on a managed network, but requires reliable internal DNS and careful handling of multiple VLANs, IPv6 and device DNS overrides.

• Direct private-IP access is simple for testing but inconvenient for certificates, changing addresses and users who move between home and external networks.

• A reverse proxy can centralise HTTPS and routing, but it does not by itself guarantee that LAN clients can reach the proxy through the public address.

Practical recommendation: if you control internal DNS and already run local services, split-horizon DNS is often a straightforward design. If you need clients to use the same external address directly, or an application discovers only a public mapping, hairpin support may still matter.

Worked example: how many address translations occur?

Techie Broadband worked example: the laptop sends 192.168.1.20:53000 to 203.0.113.10:443. A typical hairpin rule changes the destination to 192.168.1.50:443 and may change the source to 192.168.1.1:61000, a router-side address and port. The server replies to 192.168.1.1:61000; the router uses connection state to restore the endpoints the laptop expects. The translated source port is illustrative, not a fixed standard.

In that illustrative implementation there are two translation directions on the outbound packet: destination NAT and source NAT. Reverse translation is applied on the reply. This is not two journeys across the internet and does not imply two times the broadband latency. The packet remains within the local network path, although router processing and LAN topology still affect performance.

Does Hairpin NAT work with CGNAT?

Hairpin NAT on your home router does not solve carrier-grade NAT at the ISP. If your router's WAN address is private or in the shared 100.64.0.0/10 range, the public IPv4 address seen by websites may belong to an upstream ISP NAT rather than your router. A port forward on your router alone normally cannot make an inbound service reachable from the public internet through that additional layer.

Some upstream NAT environments support their own hairpinning, but you must not assume that an ISP's CGNAT will expose a home server or honour a home-router forwarding rule. Consider a public IPv4 service, an appropriate VPN or tunnel, or an IPv6 design with suitable firewall controls where supported.

Does Hairpin NAT work with IPv6?

Hairpin NAT is most often discussed in IPv4 networks using address translation. With globally routable IPv6 addresses, a LAN client can normally connect to a server's global IPv6 address without IPv4-style NAT reflection, provided routing and firewall policies allow it. Some IPv6 networks use translation or special firewall architectures, so the answer still depends on the actual design.

For address-family differences, see What is IPv6? and compare how globally routable IPv6 differs from private IPv4 behind NAT.

How to check whether your router supports Hairpin NAT

1. Confirm the local service works directly by opening its private LAN address and correct port from a different LAN device.

2. Check the router's port-forwarding rule and make sure the service is reachable from a genuinely external network, such as mobile data with WiFi disabled.

3. Find the router's actual WAN IPv4 address. Compare it with the public IPv4 reported by an external IP-check service; a mismatch can indicate upstream NAT.

4. From inside the LAN, resolve the hostname and record whether it returns the router's public IPv4, a private IPv4 or an IPv6 address.

5. Connect to the public hostname or public IPv4 and port from the LAN. Compare this result with the direct-LAN and external tests.

6. Look in the router or firewall settings for NAT loopback, hairpin NAT or NAT reflection, and inspect the product's documentation before changing rules.

7. If supported, enable or configure the feature, then retest both the internal and external paths. If unavailable, consider split-horizon DNS.

Testing note: a successful connection to the server's private address only proves local reachability. A successful connection from mobile data confirms a particular external path. The difference between those results and the LAN-to-public-address test is the useful clue for hairpin behaviour.

Common Hairpin NAT problems and fixes

• The public hostname works on mobile data but not on WiFi: test the router's NAT reflection support and check local DNS results.

• The public IP works but the hostname does not: investigate DNS records, local resolver overrides, IPv6 answers and HTTPS configuration.

• The local private IP works but the public IP fails everywhere: fix inbound reachability, firewall and port forwarding before focusing on hairpin NAT.

• The connection works for one port but not another: confirm the mapping, protocol and application listener for each service.

• The server sees an unexpected source IP: hairpin source NAT can make local clients appear to originate from the router. Adjust trusted-proxy and logging assumptions appropriately.

• A service works from one VLAN but not another: check inter-VLAN routing, firewall zones, NAT rules and internal DNS per network.

• The connection fails only behind a second router: identify double NAT and the device actually holding the public address.

Is Hairpin NAT secure?

Hairpin NAT is a routing and translation convenience, not a security product. It does not make an exposed service safer. If the same port-forwarding rule accepts connections from the internet, you still need appropriate authentication, timely updates, TLS where relevant, restrictive firewall rules and a clear reason to expose the service.

The internal service may see the router's LAN address rather than the original client address when source NAT is used. This can affect access-control lists, rate limits and audit logs. A split-horizon DNS design that connects directly to the server may preserve local client source addresses more naturally, subject to the wider network architecture.

Does Hairpin NAT affect broadband speed or latency?

The hairpinned connection normally stays within the local network. It is not constrained by the advertised broadband download or upload rate simply because a public hostname is used. The relevant limits are usually the router's NAT processing capability, LAN link speeds, switching topology, the server and the client. Poor router implementation can add overhead, but there is no universal percentage penalty.

If a client and server can communicate directly on the same switched LAN, split-horizon DNS may let traffic avoid the router's NAT processing altogether. Whether that changes throughput or latency in a measurable way depends on the equipment and topology.

Frequently asked questions

Is NAT loopback the same as Hairpin NAT?

Yes. The terms Hairpin NAT, NAT loopback and NAT reflection commonly describe the same broad behaviour: an internal client reaching an internal destination through a NAT device's external address mapping.

Do all UK broadband routers support Hairpin NAT?

No universal claim is safe. Support depends on the router model, firmware, ISP-supplied configuration and network design. Check the actual device and firmware rather than assuming the ISP brand determines support.

Can Hairpin NAT fix a failed port forward?

Only in a specific situation. It can help when the port-forward already works externally but fails from inside the LAN via the public endpoint. It cannot correct an incorrect destination address, closed service port, ISP CGNAT or a general external firewall block.

Does Hairpin NAT send my traffic onto the internet?

Normally no. The router translates and returns the traffic locally. The public-facing address is used as a destination identifier, but the packets need not traverse the ISP's access network.

Can I use the same HTTPS hostname inside and outside my house?

Yes. Hairpin NAT can make the external hostname work internally, and split-horizon DNS can provide the same hostname with different address answers. TLS certificate validity and hostname matching are separate requirements.

What if my router does not offer a Hairpin NAT setting?

Some routers support it automatically. If yours does not, you can use internal DNS overrides, a supported alternative router or a different service-access design. Avoid exposing extra ports merely to compensate for a local-access problem.

Key takeaway

Hairpin NAT lets devices inside a network reach an internal service through its external IP address and port. It is distinct from ordinary port forwarding, and it does not bypass ISP CGNAT. Test the service by private address, from outside and from inside via the public hostname before changing router settings. Where appropriate, split-horizon DNS is a practical alternative.

To explore the related technical concepts used in this Hairpin NAT (NAT Loopback) guide, visit our broadband terminology guide.