NAT is the most successful temporary solution in networking. It was meant to buy time until IPv6 arrived; instead it became the default edge design, and a generation of troubleshooting habits were built around its side effects.
You need three cases: outbound translation, inbound port forwarding, and the one that catches everyone, internal clients reaching an internal server by its public address.
The three translations
| Type | What changes | Used for |
|---|---|---|
| SNAT / masquerade | Source address | Outbound internet access |
| DNAT / port forward | Destination address and port | Publishing a service |
| Hairpin / NAT loopback | Both, for internal clients | Internal access to a public name |
A fourth, static one-to-one NAT, maps a public address to a private one in both directions. It is common for mail servers and anything that needs a stable public identity.
Outbound: SNAT
A student laptop at 10.40.12.57 opens a connection to 203.0.113.10. The firewall rewrites the
source to the district's public address and records the mapping:
10.40.12.57:51422 -> 198.51.100.5:40001 -> 203.0.113.10:443
The reply arrives addressed to 198.51.100.5:40001, and the firewall reverses the translation using
the table entry. The internal address never appears on the wire outside.
PAT (port address translation) is why one public address serves thousands of devices: the source port is what distinguishes them. It also makes inbound connections impossible without an explicit mapping, which is the security property people actually rely on.
Inbound: DNAT
Publishing a service means mapping a public port to an internal address:
198.51.100.5:443 -> 10.0.0.40:443
Two details decide whether it works:
- The firewall rule must exist for the translated destination, not just the public address. Many platforms evaluate policy after translation, some before. Know which yours does.
- The return path must be symmetric. If the server's default gateway is not the firewall, replies leave directly and the client sees a timeout. This is the most common port-forward failure.
The hairpin problem
An internal client types the public URL. The DNS name resolves to 198.51.100.5. The client sends the
packet to the firewall, which forwards it to 10.0.0.40. The server replies directly to the client,
whose source address is internal — but the client expects the reply to come from 198.51.100.5, so it
discards it.
The fix is hairpin NAT: translate the source as well, so the server sees the firewall's internal address and replies through it. On UniFi this is a NAT rule, not a port forward setting, and forgetting it produces "the site works from home but not from the staff VLAN."
Protocols that embed addresses
Some protocols put IP addresses inside the payload. Translation rewrites the header, not the payload, so the far end sees an address it cannot reach.
| Protocol | Problem | Mitigation |
|---|---|---|
| SIP | Contact and SDP headers carry addresses | SIP ALG, or a session border controller |
| FTP (active) | Server opens a data connection back | Passive mode, or an ALG |
| IPsec IKE | Identities and NAT-T | NAT-T, or avoid NAT between peers |
| H.323 | Addresses in call setup | ALG, often poorly implemented |
SIP is the one that bites in a district. A 3CX host behind NAT needs its external address configured in the PBX itself, not just a port forward, or calls connect and have no audio.
Double NAT is not a security layer
Two layers of translation make inbound services harder to publish, break protocols twice, and hide the real source address from logs. If you inherit it, flatten it.
Worked example: publishing an internal web app
Goal: helpdesk.marionisd.net reachable from outside and inside.
- External DNS: A record to
198.51.100.5. - Port forward:
198.51.100.5:443→10.0.0.40:443. - Firewall rule: WAN → Infrastructure, destination
10.0.0.40, port 443, allow. - Server gateway: default route points at the firewall, so replies are symmetric.
- Hairpin: NAT rule translating Internal source to the firewall's internal address for that destination.
- Test: from outside, from a staff VLAN, and from a student VLAN (which may be blocked by design).
Steps 4 and 5 are the ones that fail silently. Everything looks correct until someone tests from inside.
What breaks in production
- Asymmetric return. The server's gateway is not the firewall; replies bypass it and clients time out.
- Missing hairpin. Works externally, fails internally, and the ticket says "the site is down."
- ALG disabled or doubled. SIP registers but has no audio; enabling the ALG on two devices makes it worse.
- Port forward without a policy rule (or a policy rule for the pre-translation address).
- Stale forwards. A decommissioned server's port stays open for years, pointed at an address that now belongs to something else.
Checklist
- Every outbound flow is translated at the edge, and the table size is monitored.
- Each port forward has a matching firewall rule and a symmetric return path.
- Hairpin NAT exists for every published service that internal users also reach by name.
- SIP and other address-embedding protocols have an explicit plan, not a default ALG.
- No double NAT anywhere on the path.
- Decommissioned forwards are removed in the same change as the server.
Next
The mechanics are clear. Continue with Writing Policy You Can Defend, where the hard part is naming, documenting, and proving intent.