Could you please advise about the point of SNAT (AutoMAP); When should I enable it? I mean this bit of information that the server has GW path to router instead of having a next hop to F5 (floating/ self-IP), should this information be provided by the application owner?
To be more spacific; how could I know if I have to enable (automap) or leave it as blank (no)? I see that some of VS have no SNAT and they work normally, on the other side there are some others required enabling (automap) to avoid connection reset from production machine.
this is more a network design question. As you already stated, it's a question where the GW of the servers are pointing to. And of course if the BIG-IP itself has an IP interface in the same VLAN as the servers. But if you are looking to a more generell answer, you need to guarantee, that the response traffic from the server has to go back through the BIG-IP. With SNAT enabled response traffic is forced to go back through the BIG-IP. Otherwise the client is getting the response from the servers IP instead of the VIP. Yes, there might be exceptions for this allowing asynchronous routing, but that's not recommended.
And I don't think your application owner will answer you this question. They normally have no idea about the underlying network design. You as the BIG-IP service owner should have the required network information and knowledge. Also a mixed setup, like it seems to be configured in your case, within the same environment is not recommended.
The main disadvantage of using SNAT is, that the original sourceIP gets lost for the server. For HTTP-traffic you can use the XFF-header, but for other protocols this might be an issue.
Hope that helps!
Regards Stefan 🙂
@AhmedMS to add to what @Stefan_Klotz has stated because that is all correct. AutoMap does enable SNAT but it uses the self-IP of the interface closest to the pool member that you are balancing traffic to. By closest I mean whichever route on the F5 will get you to the destination pool member then that is the interface self-IP that the F5 will use to SNAT traffic. A word of caution, the self-IP of the F5 is used for health monitors and various other tasks so using AutoMap in a high connection environment might put you in a situation where you exaust the ephemeral ports on the self-IP of the F5 which can cause issues with health monitors to pool members and other communication. It is always recommended to use the SNAT pool feature over AutoMap for this reason unless AutoMap is the only configuration that will work for your situation. Typically when you configure a SNAT pool the IP in that pool will be the same IP as the virtual server (VS) that you are configuring SNAT for and in some cases of a high connection virtual server you will want to configure a range IPs so that you do not encounter port exaustion on the SNAT IP.
I'd say @Stefan_Klotz has the correct answer: to SNAT or not to SNAT is mostly a question of making sure the response traffic comes back through the F5 box.
In most green field scenarios what I like to do is to get the server vlan "behind" the F5, and create an "IP forwarding" virtual server so that F5 can route traffic properly. That way you may configure your servers' default gateway with F5's address.
Not using SNAT ensures you send unchanged layer-3 source IPs to the real server. Maybe the server has specific rules depending on the source IP, or you just want proper logging.
If you do need SNAT, and as Stefan mentioned, the HTTP protocol has the option of using the XFF header, which you can use to insert the original source IP. You can activate that directly in the HTTP profile in F5 (the header will be called "X-Forwarded-For"), or you can get creative with the header name with an iRule - see https://my.f5.com/manage/s/article/K4816.
Note that to insert XFF in HTTPS traffic, you need to decrypt traffic, You need at least a Client-SSL profile and an HTTP profile attached to the virtual server; if server traffic is to be encrypted you must add a Server-SSL profile.
Some protocols (not many that I know of...) have similar features to XFF. For instance, SIP uses the "Via" and "Route" headers.
One remark to @Paulius in regards to the ephemeral ports topic, you can also create several floating self-IPs on the same VLAN so you can still use the default Automap feature. The BIG-IP will then rotate across all available floating self-IPs in this VLAN. For more details about SNAT you can also have a look at K7820.
Regards Stefan 🙂
Thanks alot for your answers. You made it clear, much appreciated.
So, is it doesn't make a sense to have mixed setup like that. Right?
Regarding the point that an App faced an issue of connection reset, but when automap got enabled, it worked fine!! However, there are some other Apps that work with no SNAT at all.
Hi @AhmedMS ,
I don't think it makes sense to have a mixed scenario (SNAT / no SNAT) when *all* routing conditions are equal.
Be aware that servers may be connected to multiple networks and their default gateway might not be what you expect. SNAT may be needed in such conditions.
If you want to clear your SNAT configuration, confirm first the routing table of the servers where you are sending traffic to. That way you can understand what path will the response traffic take.