06 SNAT, NAT and Return Traffic
In a full proxy, return traffic must come back through BIG-IP. If a server replies straight to the client, the client receives a packet from an IP it never talked to and drops it. SNAT is the usual way to guarantee the return path; this note explains NAT vs SNAT, the SNAT types, port exhaustion, keeping the client IP with X-Forwarded-For, and the alternatives to SNAT.
How addresses change along the path
- IP addresses stay the same end to end (unless NAT/SNAT changes them).
- MAC addresses change at every Layer 3 hop: each router rewrites source and destination MAC.
NAT vs SNAT on BIG-IP
| NAT | SNAT | |
|---|---|---|
| Mapping | 1 to 1, both directions | Many to one, source only |
| Initiated from | Either side | The client side |
| Typical use | Give one server its own public IP (inbound + outbound) | Force return traffic through BIG-IP; outbound Internet for servers |
| Where | Local Traffic → Address Translation → NAT | On the VS (Auto Map / SNAT pool) or a standalone SNAT listener |
Standard NAT and the gateway
A plain NAT only works if the servers use BIG-IP as their default gateway, because the return traffic has to come back through it.
What SNAT does
BIG-IP replaces the client’s source IP with one of its own IPs toward the pool member. The member replies to BIG-IP, and BIG-IP translates back.
| Step | Source IP | Destination IP |
|---|---|---|
| Client → VS | 172.16.101.5 | 172.16.101.20 (VIP) |
| BIG-IP → member | 10.10.101.11 (SNAT) | 10.10.101.103 (member) |
| Member → BIG-IP | 10.10.101.103 | 10.10.101.11 |
| BIG-IP → client | 172.16.101.20 (VIP) | 172.16.101.5 |
Configured on the VS with Source Address Translation: None (default) · Auto Map · SNAT (pool).
When SNAT is required
- One-arm deployments (clients and servers reachable through the same VLAN/router).
- Servers whose default gateway is not BIG-IP.
- Clients on the same subnet as the servers (the server would reply directly).
- VS-to-VS traffic (multi-tier applications).
Auto Map vs SNAT pool
- Auto Map — uses BIG-IP’s self IPs on the egress VLAN; a floating self IP is preferred when it exists (so it survives failover).
- SNAT pool — a dedicated list of translation IPs. Use it when you need more scale or want to control which IPs the servers see.
Port exhaustion
Each SNAT IP can hold about 65,535 source ports toward the same destination (member IP:port). Above that, connections fail, so add IPs to a SNAT pool:
| Concurrent connections to the same member | SNAT IPs needed |
|---|---|
| Up to ~64,000 | 1 (Auto Map is fine) |
| 70,000 | 2 |
| 100,000–150,000 | 3 |
Intelligent SNAT (iSNAT)
Maps specific traffic to a specific SNAT IP with an iRule:
- Create a data group with the client IPs (or ports) to match.
- Create an iRule that checks the data group and, on a match, applies
snat <ip>(or a SNAT pool).
Use case: internal users must always reach the application from the same few IPs because the app makes decisions based on source IP.
Keeping the original client IP (X-Forwarded-For)
SNAT hides the client’s IP from the server. For HTTP applications:
- Enable Insert X-Forwarded-For in the HTTP profile, or use an iRule that inserts the header.
- Configure the web server to trust BIG-IP’s IPs and read the header (NGINX:
set_real_ip_from+real_ip_header X-Forwarded-For).
HTTP only
X-Forwarded-For is an HTTP header. A non-web application (e.g. a custom TCP service on port 34341) can’t use it — use routing instead of SNAT there.
Returning traffic without SNAT
- Servers’ default gateway = BIG-IP’s floating self IP (classic two-arm design).
- Specific routes on the servers, or policy-based routing on the upstream router.
- Auto Last Hop (enabled by default) handles the client side: BIG-IP remembers the source MAC and VLAN each connection arrived on and replies to that same hop, even without a route back to the client network. It can be disabled globally, per VLAN, per SNAT/NAT or per VS.
- DevCentral’s “Kill SNAT Automap” approach: route the return traffic to BIG-IP instead of translating.
SNAT is not the only way to bring return traffic back through the LTM.
Egress source IP — quick reference
- No SNAT → source = the original client IP.
- SNAT Auto Map → source = BIG-IP’s self IP on the egress VLAN (
10.10.101.11in the lab). - SNAT pool → one of the pool IPs.
Self-check
Q1 — Within an Ethernet frame, do source and destination MACs stay the same across several networks?
Respuesta
No. MACs change at every Layer 3 hop; IPs stay the same unless NAT is used.
Q2 — True or false: standard NAT on BIG-IP only works when members use BIG-IP as their default gateway.
Respuesta
True.
Q3 — With SNAT, what's the source IP of the packet from BIG-IP's internal interface to the pool member?
Respuesta
The IP address of BIG-IP’s internal self IP (with Auto Map).
Q4 — An application will have about 70,000 active connections. Which SNAT option?
Respuesta
A SNAT pool with 2 IP addresses.
Q5 — Expected 100,000 connections, growing to 150,000 at peak?
Respuesta
A SNAT pool with 3 IP addresses.
Q6 — What two things are needed for iSNAT?
Respuesta
A data group with the IPs or ports, and an iRule that maps the data group to a SNAT IP.
Q7 — A web application needs the original client IP but you use SNAT. What feature solves it?
Respuesta
The X-Forwarded-For HTTP header.
Q8 — Is SNAT the only way to make return traffic pass through the LTM?
Respuesta
No. Servers can use BIG-IP as their gateway, or routing can send the replies back to it.