SNAT is also known as Secure Network Address Translation (SNAT). It is an object that maps the source customer IP address in a request to a translation address defined on the BIG-IP device.
Source network address translation, or secure network address translation what is correct. Well technically right is secure address translation but source address translation is easier to remember as source address is translated by the snat of the incoming connection or packet. The main use of snat is in the case of single arm deployment of bigip device or you can say when the internal server or members are configured to have default gateway or default route other than the bigip address .it means that the reply to the client that the server will generate will be forwarded to the default gateway if that default gateway is not bigip and it is other device like firewall or router then definitely then connection will be dropped by bigip being a stateful device.
So in these kind of scenario the snat comes handy and the source address of the client will be translated to the bigip egress vlan selfip address which is not the default behavior of the bigip and this case the source translated ip address will be of the subnet of the server so the response generated by the servers will be through the bigip devie even the gateway configuration on the server pointing towards another device like router or firewall.
Brief description a SNAT is made of up three components:
SNATs are either global (i.e. traffic coming through a LTM®), or they can be associated with a Virtual Server.
Outbound Traffic – A common problem solved with SNAT is translating the source address of many hosts on an internal non Internet routable subnet to one external Internet routable address. It’s not the same but is a similar concept as how your home router works. When traffic hits the BIG-IP, the “origin” would equate to an “address list” you specify with all the hosts in it or “all addresses” for that specific VLAN, (in this example) the “Translation” would be one single address. When traffic returns to the BIG-IP from the destination it is then translated back to the original origin address.
Hopefully after reading this article you have a better understanding of the inner workings of SNAT.
The SNAT automap feature is going change the source address of the communication to the self-ip of the exit interface in a specific order of preference. Again, this is so the communication comes back to the load balancer. Otherwise the destination host would route around the load balancer when communicating back to the client, resulting in asymmetric traffic. Unless of course the servers have the Local Traffic Manager (LTM) as their gateway, which I discuss in the “inline” section below.
To put it simply, you need SNAT when using the BIG-IP because the F5 is a stateful Full Proxy. Traffic passing through it needs to return through it, otherwise the connection will break. I’ve put together this picture to depict a common inbound SNAT scenario, where the servers do NOT point to the BIG-IP as their GW, rather they point to a layer 3 device – router. Step 5a depicts the scenario where SNAT IS turned on at the VIP, and traffic is sent back to the F5 BIG-IP that is part of the directly connected subnet of the pool members.
Another common situation you should be mindful of when deciding if SNAT is needed or not is to consider if servers will ever need to source traffic to VIPs that have pool members on the same subnet as the servers originating communication.
If they do, then you definitely want to consider using SNAT, or using an iRule to SNAT traffic sourced by the servers. If you don’t use SNAT in that situation the return traffic from the servers will go directly back to the source host on the same subnet bypassing the F5 BIG-IP and breaking communication.
Instructor-led training for F5 Certification courses available here: https://www.uninets.com/load-balancer/f5-big-ip/