When BIG-IP load-balances a connection, by default it preserves the client's source IP toward the pool member. The member sees the real client address, which is often what you want, but it creates a routing requirement that is easy to miss.
The asymmetric-routing trap
A TCP connection only works if both directions flow through the same device that is tracking its state. BIG-IP is tracking the connection, so the member's reply has to come back through BIG-IP. If the member's own default route points at the network's router rather than at BIG-IP, the member will send its reply directly toward the client's IP, bypassing BIG-IP entirely. The client then receives a packet from an address it never opened a connection to, and drops it. This is asymmetric routing: the request went one way, the response tried to go another, and the connection stalls. It is one of the most common "the virtual server is up but nothing works" causes.
What SNAT does
(source network address translation) fixes this by changing the source address BIG-IP uses toward the member. Instead of the client's IP, the member sees a BIG-IP-owned address, either an automatically chosen self IP (SNAT automap) or an address from a defined SNAT pool. Now the member's reply is naturally addressed back to BIG-IP, which forwards it to the client, and the path is symmetric no matter how the member's routing is set up.
The cost and its mitigation
SNAT trades away the real client IP: because the member now sees a BIG-IP address as the source, it can no longer log or make decisions based on the true client address. For HTTP this is usually handled by inserting an X-Forwarded-For header carrying the original client IP, so the application can still see it. In bigip.conf this shows up as a snat-type automap on the virtual server or an attached snatpool. The rule of thumb is that SNAT is what you reach for when you cannot guarantee the members route return traffic back through BIG-IP, which on most real networks is exactly the situation.
SNAT solves routing and buys you a port ceiling
Turning on SNAT fixes the asymmetry, because the member now replies to the BIG-IP address it was talked to. It also introduces a limit that only appears under load.
Every connection from a SNAT address to a given destination needs its own source port, and there are roughly 64,000 of them per address-destination pair. A busy virtual server fronting a small number of pool members can exhaust that range, and when it does, new connections fail while every member monitor stays green. It looks like a backend problem and it is an arithmetic problem — the fix is more SNAT addresses, not more servers.
The other cost is attribution. The member no longer sees the client's address, so unless the profile inserts an X-Forwarded-For header and the application logs it, the access logs record only the SNAT address. Discovering that during an incident is discovering it too late.