Address Translation and the F5 BIG-IP

We’ll dive into detail explanations on the 3 ways the BigIP can perform address translation:

• SNAT
• NAT
• Virtual Servers



What is SNAT?

I’ve seen SNAT referenced two ways in F5s documentation, Source Network Address Translation, and Secure Network Address Translation, both of which are correct. “Source” makes it’s easier to understand, because you are translating the “source” addresses of the client initiating traffic or as the devices references it the “origin”. It’s “Secure” because you can’t initiate traffic to a SNAT, the “translation” addresses are never known by the host initiating the traffic. In short a SNAT is made of up three components:
• Translation – Options: an IP address (single address), a SNAT Pool (multiple addresses), or an Automap(self IP(s) of the Local Traffic Manager). This is what the Source address of the client is translated to.
• Origin – Options: All addresses (everything coming in on the VLAN you specify, or an Address list (specific addresses you provide). These are indeed the source addresses of the client.
• VLAN Traffic – Options: All Vlans (every VLAN), Enabled on (only on the vlans specified), or Disabled on (on all vlans except the ones you specify)
The most common misunderstanding is how SNAT can be used. Unlike a traditional NAT, you can’t send traffic to a SNAT address.  SNATs are either global (ie traffic coming through a LTM), or they can be associated with a Virtual Server.   The first option is the hardest to get your head around, the second option, associating with a Virtual Server, is a lot easier to grasp and is usually everyone’s first exposure to SNAT, using “SNAT automap” applied to a virtual server.  In both examples SNAT is generally used to solve routing issues and can be used with a variety of mappings but not limited to, one to one, many to one, all to one, etc etc.  Let’s dive into the first option and see if we can get a better understanding of SNAT not applied to a Virtual Server, but affecting the LTM globally.

Global traffic and SNAT

Outbound Traffic- Translating the source address of many hosts on an internal non Internet routable subnet to one external Internet routable address is a common problem solved with SNAT.  Think about how your home router works, it’s not the same but is a similar concept.  When traffic hits the BigIP the ”origin” would equate to an “address list” you specify with all the hosts in it or “all addresses” for that specific VLAN, the “Translation” would be one single address.(in this example).  The destination addresses now sees the “Translation” address as your new source.  When traffic returns to the BigIP from the destination it is then translated back to the original origin address.  It’s important to note, by default SNATs are allowed on all VLANs, but you can get more granular and split them out between multiple VLANs.

Virtual Servers and SNAT

Inbound Traffic- Virtual Servers can have SNATs applied to them effectively changing the source of the Client initiating traffic to the VS. Here’s the really cool part about SNATing, with SNAT anything you can route to you can load balance to! That my F5ers is a beautiful thing! You see, in most cases, the servers you want to load balance are NOT going to have the BigIP as their gateway, so unless you translate the source address to something that belongs to the BigIP, you’re going to end up routing “around” the BigIP and not “through” the BigIP.  Resulting in your VS not working and what we call asymmetrical routing, a fancy term for traffic taking different routing paths in one direction or the other. Asymmetrical routing is not always going to break traffic, but when dealing with a stateful device, something that maintains a connection like the Full Proxy BigIP, asymmetrical routing can break your communication.

What is SNAT automap, a simple explanation

Everyone’s first exposure to SNAT is usually SNAT automap. A lot of organizations at some point just turn this on without a good understanding of SNAT. 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.

SNAT automap order of preference

AJ asked a good question in the comments below that merits an update to this article, and it pertains to “order of preference”. Automap is going to select the source address from available Self-IPs in a specific order of preference as follows:
1. Floating Self-IP addresses on the egress VLAN
2. Floating self IP addresses on different VLANs
3. Non-floating self IP addresses on the egress VLAN
4. Non-floating self IP addresses on different VLANs
One of the main reason it prefers the float is, you got it AJ, in scenarios where there is a HA configuration and a failover event occurs we want to make sure the return traffic follows the newly activated device / traffic group.

Alternative to SNAT,  Inline

An Alternative to SNAT would be an Inline design. Having the servers in your pool Inline means they will need the Load Balancer as their Gateway address.  As inconvenient as this might sound vs. the “anything you can route to you can load balance” approach, there are definitely reasons why one might choose to go inline vs SNAT.  The one major thing you lose with SNAT, or gain depending on your perspective, is the clients source address. With an inline approach, you preserve the source address.  Some applications and logging systems want to see the “real” source IP of a connection.  When you use SNAT, that is replaced by one of the options you specify.   One could also make the argument an Inline approach is slightly faster than a SNAT approach, but again.. that might start an argument 😉

How do I capture my source address with SNAT?

So now you’re SNATing, you feel cool, you look cool, well you are cool!  You’re load balancing anything you can route to, life is good and server administers are happy they didn’t have to jack around their servers and change their gateway. Until they look in their logs and are confused what happened to all the source address information! Fortunately, if you’re dealing with web based traffic we can still provide this information to them, it’s just going to require a little bit of reconfiguration on their side as well as yours. Enter the XFF header option! The X-Forwarded-For header option when enabled will capture the source address of the client and append it in the header.  The logging server would then need to be configured to grab this value instead of looking at the actual source address. I’d like to note a few gotchas / limitations here:
• Encrypted Web Traffic – If your web traffic is encrypted you’re going to need to terminate SSL at the BIG-IP. In other words you’re going to need to host the certificate / key and associate them in a clientside ssl profile with the virtual server(s) in question. This might seem like a pain at first, but trust me, it’s a GOOD thing. Managing your SSL certs/keys on the F5 will save you time, money, and a lot of headaches. You’ll even save precious CPU cycles on your servers if you choose not to re-encrypt on the serverside.
• Non Web Traffic – If you’re not dealing with web traffic your options are limited. The only way you will be able to log the client source address is to capture it from an iRule and log it locally at the BIG-IP device. Script away and you could even ship that info off automatically to the people or systems who need it.

What is a NAT?

NATs are a one to one mapping between addresses. Unlike SNATs and Virtual servers, NATs can be used for traffic initiated in both Directions. You can Send Traffic to the NAT address or the Origin address can send traffic to any address – as long as that origin address passes through the BIG-IP of course ;). NATs are not connection based like SNATs, ie they are not tracked by the BigIP. A NAT is made up of two major components:
• NAT address – The NATs address is the routable address on the external network of the BIG-IP system. It should not be the same address of the mgmt IP as well as the originating or translated IP address defined for a SNAT.
• Origin Address – You can think of this as the internal address. I know, I know.. confusing, because “origin” when talking SNAT is an external address or address list, but in this case you need to think of it differently. It’s important to note a Virtual Server can’t use this IP address.

Why Do I Need SNAT?

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. Ty Iyad for bringing up that situation in the comments – it’s an important one to consider!

Here’s a detailed description of the traffic path with NO SNAT enabled.
1. The client with the source address of 10.10.100.75 makes a request to 10.10.10.50, a VIP that lives on the BIG-IP. Since it’s not directly connected to the client, it sends the traffic to its’ gateway – 10.10.100.1
2. The router receives the traffic and forwards it out of the directly connected VIP 10.10.10.50
3. The VIP receives the traffic, since NO SNAT is enabled, it does not change the source address of the communication, and forwards it to the respective pool member, lets pick 172.16.1.19. At this point the source of the communication is still the client, 10.10.100.75, destined for 172.16.1.19.
4. This is the point where the communication starts to go bad, and breaky breaky begins. The pool member 172.16.1.19 receives the traffic, and since 10.10.100.75 isn’t directly connected, it sends the traffic out of its’ default gateway – 172.16.1.1.
5. The router receives the traffic sourced from the pool member destined back to the client. The router sends the traffic out of its’ directly connected subnet and back to the client. The client is expecting the VIP of 10.10.10.50 to respond back, not the pool member. The client doesn’t recognize the connection and the communication breaks – this is known as asymmetric routing around a stateful device.
Do you see how this could have be fixed? You have two options:
1. Change the gateways of the servers to the BIG-IP inside trusted subnet floating IP of 172.16.1.5, this will not only fix the asymmetric routing, but it preserves the real source IP of the communication. You can imagine this communication coming back down step 3 since they’re on the same subnet and directly connected.
2. Turn SNAT on at the 10.10.10.50 VIP. If you used SNAT Automap, it would use the Floating IP to source communication to the pool members. You can see this alternative directly connected traffic path depicted in (5a) – this is known as symmetric routing through a stateful device.