A green pool does not tell you whether a user's connection can complete. If a BIG-IP virtual server accepts traffic but the application times out, the useful question is: what source address did the backend receive, and where did it send the reply? F5 documents SNAT as a way to make backend replies return through BIG-IP when the server's normal route would take them elsewhere.[1]
This guide separates return-path failures from SNAT port pressure. It includes a reusable troubleshooting matrix, read-only commands, a design decision table and a cutover acceptance checklist. Scope: conventional BIG-IP TMOS/LTM load-balanced TCP services, not BIG-IP Next, direct server return or a universal configuration recipe. Examples are hypothetical and commands have not been executed on a BIG-IP appliance.
First decision: is this routing, translation or capacity?
Use this sequence before changing the virtual server:
- Choose one failing client, one virtual IP (VIP), one backend and a precise test time.
- Check whether the connection reaches the intended virtual server.
- Identify the selected backend and the actual server-side source address.
- Check the backend's route to that observed source, not merely its default gateway.
- Compare a failed connection with a successful one, preferably against the same backend.
- Only investigate translation capacity as the leading hypothesis when load, destination concentration or allocation evidence supports it.
These are proposed diagnostic steps, not claims that any single symptom proves the cause. If the pool is genuinely unavailable, start with the companion F5 health monitor troubleshooting matrix instead of treating SNAT as the first fix.
Why SNAT fixes some one-arm failures
Without source translation, a backend can receive the original client address and use a route that bypasses BIG-IP for its reply; F5 specifically identifies configurations with a different backend gateway, or clients and servers sharing a subnet, as cases requiring return-path attention.[1]
With SNAT, BIG-IP substitutes a translation address as the server-side source, and the backend replies to that address.[1] This changes the routing problem, but it does not excuse an unreachable translation address or a firewall policy that blocks the resulting flow.
Read both connection legs
For a hypothetical HTTPS service, record the client-side tuple as CLIENT:ephemeral → VIP:443 and the server-side tuple as TRANSLATION:ephemeral → BACKEND:443. If SNAT is absent, expect the original client address on the server side instead. The BIG-IP connection table provides separate client-side and server-side address and port filters for inspecting these legs.[3]
Do not assume the server-side source port equals the client's source port. The virtual-server configuration has a separate source-port setting; inspect it rather than inferring it from the SNAT address selection.[2]
One-arm vs two-arm: choose by return-path ownership
The table below is an engineering decision aid, not an F5 platform requirement. The important property is a verified return path through the connection-handling BIG-IP, rather than how many physical interfaces the appliance has.
| Design choice | When to consider it | Evidence required before approval |
|---|---|---|
| One-arm with SNAT | You cannot change the backend gateway and can accept translated network-layer client identity | Backend reaches every translation address; application logging still meets requirements |
| One-arm without SNAT | Explicit routing already brings backend replies through BIG-IP | Route lookup and packet evidence for each relevant client network, including local clients |
| Two-arm with routed return path | You control server-side routing and need original client addresses at the network layer | Normal and failover routes both traverse the intended BIG-IP |
| Two-arm with SNAT | Routing or operational requirements still favor explicit source translation | Same translation, capacity and identity checks as the one-arm case |
Do not approve “two-arm means no SNAT” as a design rule. Ask for the route lookup and a connection trace. Likewise, do not remove SNAT just to improve backend logs without validating the new return path.
Automap vs a dedicated SNAT pool
F5's virtual-server reference defines automap as using self IP addresses for source translation, while snat uses a configured SNAT pool.[2] F5 also documents assigning a SNAT pool directly as a virtual-server resource.[1]
For a modest service, automap can be a simple operational choice. For a service needing an explicit address inventory, clear downstream allowlists or separately planned translation capacity, evaluate a dedicated pool. These are design recommendations, not promises that a dedicated pool is automatically faster.
Before selecting either, write down:
- Which translation addresses the backend can actually see.
- Which routes, neighbor entries and downstream firewall rules make those addresses reachable.
- Which HA traffic group and ownership behavior apply to those addresses.
- Whether other services share the same translation addresses.
- Whether backend security controls require the original network-layer client IP.
For HTTP services, involve the application/security owner in the client-identity design. Treat forwarded identity headers as a trust-boundary decision: agree which proxy supplies them and how untrusted client-supplied values are handled. Do not assume such headers solve identity requirements for arbitrary TCP services or TLS passthrough.
Read-only workflow: prove what the flow is doing
Unexecuted examples: run from an authorized BIG-IP shell with tmsh available. /Common/vs_example is a placeholder, not an existing object. Validate syntax with local help on the installed TMOS release; documentation versions do not establish appliance support status.
tmsh list ltm virtual /Common/vs_example all-properties
tmsh show ltm virtual /Common/vs_example
tmsh show sys connection virtual-server /Common/vs_example
tmsh list ltm global-settings traffic-control all-properties
The virtual-server commands expose configuration and status, including source-address translation, attached profiles, rules and policies.[2] The connection command can filter by virtual server and by the individual client-side/server-side address and port fields.[3] F5 documents the traffic-control query for inspecting ephemeral-port warning settings.[1]
On a busy appliance, add approved filters from tmsh help sys connection to constrain output to the failing flow. Avoid an unrestricted connection-table dump unless its operational impact has been reviewed. Do not delete connections, reset counters or modify timeouts as part of evidence gathering. F5 warns that a connection deletion without an IP filter can delete all connections, including mirrored connections.[3]
Record this worksheet for each controlled request:
| Field | Value to capture |
|---|---|
| Test identity | Timestamp, client network, requested hostname and application operation |
| Client-side tuple | Client address/port and VIP address/port |
| Server-side tuple | Actual source address/port and backend address/port |
| Routing | Backend route to the actual server-side source |
| Packet outcome | SYN, SYN-ACK, completed handshake, reset or retransmission |
| Application outcome | TLS result, response code and transaction success |
| Configuration context | Virtual server, selected pool member, translation mode and relevant policy |
If packet captures are needed, use an approved narrow filter, short duration and controlled test account. Treat captures as sensitive data; avoid collecting production credentials or payloads merely to prove a TCP handshake.
Troubleshooting matrix: symptom, evidence, next action
The following matrix is an original diagnostic checklist. Its entries are hypotheses to test, not guaranteed mappings from symptom to root cause.
| Observed symptom | Evidence to collect | Next action |
|---|---|---|
| VIP times out, backend answers directly | Actual server-side source and backend route to it | Investigate bypass routing; compare approved routed-return and SNAT designs |
| Only same-subnet clients fail | Backend neighbor/route decision for those clients | Check whether replies travel directly to the client instead of through BIG-IP |
| Only one member fails | Matched connection traces to healthy and failing members | Compare routes, host firewall policy and service binding before changing the whole VIP |
| New connections fail at peaks; existing ones continue | Translation allocation evidence, per-backend concentration and connection lifetime | Investigate SNAT port pressure alongside application limits, connection limits and resource use |
| Backend sees an unexpected source | Effective connection tuple plus virtual-server rules/policies | Identify the actual translation decision before changing allowlists |
| Failure begins after HA switchover | Address ownership, route/neighbor convergence and new vs existing flow results | Separate reachability failure from session continuity failure |
| TCP works, TLS or login fails | TLS handshake and application transaction evidence | Move to certificates, SNI, profiles, persistence or application diagnosis |
F5 documents that ephemeral-port exhaustion can prevent additional SNAT connections until source ports become available; that is why new-flow failures deserve separate investigation from established-flow behavior.[1]
SNAT port exhaustion: do not size from users alone
A statement such as “one address supports a fixed number of users” hides the variables you need. For planning, ask for measured server-side connections, their destination distribution and how long translation resources stay occupied. Do not treat browser sessions, HTTP requests and TCP connections as interchangeable counters.
Use this workload worksheet before requesting more translation addresses:
| Input | Why to record it |
|---|---|
| New server-side connections per second | Establishes connection arrival pressure, not just request rate |
| Connection duration and idle behavior | Helps explain why resources remain occupied |
| Hottest backend IP and service port | Reveals concentration concealed by whole-pool totals |
| Actual translation addresses in use | Confirms the configured pool is being used as intended |
| Backend distribution during maintenance | Tests the case where fewer destinations carry the workload |
| Port allocation warnings and failed new flows | Connects a capacity hypothesis to operational evidence |
F5 provides ephemeral-port threshold warnings and associated logging/SNMP mechanisms.[1] Importantly, the documented port-find-threshold-trigger represents attempts to find an unused outbound port, not a percentage of ports consumed.[1] Do not present a trigger value as utilization in a dashboard.
If evidence supports port pressure, evaluate additional properly routed SNAT addresses, connection reuse where application-compatible, and the cause of unexpectedly long-lived connections. Validate changes under representative destination concentration and backend maintenance conditions. Do not shorten production timeouts simply to make an alert disappear.
Change and rollback checklist
Use this as an acceptance asset in a change ticket. Define success thresholds with the application owner before the window; the article supplies no invented performance baseline.
Before the change
- Export the current virtual-server and related object configuration through the approved backup process.
- Record the current translation mode, pool references and exact rollback configuration.
- Confirm that proposed translation addresses are allocated, unique and reachable.
- Confirm address ownership and configuration synchronization expectations for the HA design.
- Baseline new-connection success, error rate, transaction latency and backend-visible source addresses.
- Agree who can stop the change and what triggers rollback.
Acceptance tests
| Test | Pass evidence |
|---|---|
| Remote client transaction | Correct VIP, intended member, completed application transaction |
| Local/hairpin client if supported | Reply follows the intended path; same application checks pass |
| Every backend member | Each member tested, not merely one successful load-balanced request |
| Agreed peak workload | New-connection success and latency meet pre-agreed thresholds |
| Backend maintenance scenario | Remaining members and translation resources handle the agreed load |
| Approved HA failover | New-flow recovery measured; existing-flow continuity assessed separately |
| Application identity audit | Backend logs and access controls meet the approved identity design |
Rollback
Restore the captured configuration through the established change mechanism if acceptance fails. Retest with fresh client connections; do not assume existing sessions reflect a new translation policy. Avoid deleting a SNAT pool that other services still reference, and do not globally flush sessions to force a clean result.
Practical takeaway
Prove the tuple, prove the return route, then prove capacity. SNAT is a deliberate design choice, not a substitute for tracing a failed connection. Keep the worksheet and test matrix with the service runbook so the next engineer can distinguish a backend routing problem from translation pressure without guessing.
Continue with the Data Center networking hub or Start Here. The design tables and checklists above are original editorial assets; the following official F5 sources support the cited platform behavior and command syntax.
Post a Comment