Forum Discussion
Kevin and I just chatted about this. He meant his post to say "In the absence of SNAT you must ensure that the servers cannot route around the BIG-IP".
SNAT is pretty simple; it just replaces the original source IP address with an IP address that is assigned to the BIG-IP and [usually] on the same subnet as the target servers. The servers thus don't see the original IP, and therefore don't need any routing information about how to get a return packet to the client. Instead, they just send it "locally" to the SNAT address that BIG-IP used to replace the original. When BIG-IP sees the return packet, it replaces the original source IP as the new destination, replaces the server Ip address with that of the original target BIG-IP virtual server, and sends the packet on its way.
Since the source IP address has been replaced when the packets hit the web servers, IP-level filtering won't be effective, since everything will just look like it comes from the BIG-IP.
Without SNAT, servers will try to return a packet using whatever routing information they have. The default gateway and/or network-specific routes on servers are unlikely to be through the BIG-IP (unless you've specifically configured them that way), and are more likely to be through some router or firewall elsewhere on the network. The original client, or even an intervening firewall, will see a mis-match between the original packet (source: client; destination: a BIG-IP virtual server address) and the reply (source: a server IP address; destination: the client) and will drop the packet.
With SNAT, the packets would match:
1: (source: client; destination: a BIG-IP virtual server address)
2: reply (source: BIG-IP virtual server address; destination: the client) and will drop the packet.
There's a good article on SNAT here: http://www.wtit.com/what-is-snat-in-f5-load-balancing-snat-vs-inline-what-is-nat/