Confusion on SNAT and source IP/Ports

Network > Routes tab to add the routes.

 

 

To get the client IP, you need to set up a virtual forwarder on the LTM, and use it as a gateway, or do the second NIC as described. I don't personally like that solution too much.

 

 

Alternatively, if this is a Web App, you can insert X-Forwarded-For headers and set up IIS to pick that up. Easiest solution by far.

 

 

Jeff

Hey Adam - I would suggest a few things to think about that may help resolve your issue, possibly without doing anything related to network / server reconfiguration. First, logging source IP address does *not* make a deployment more secure in and of itself. In fact, by the time the source address is written to the log, the connection is already established and it provides no security benefit other than its historical security audit/forensics value. The process of actually using SNAT combined with the security features of the LTM (or ASM, or any security device for that matter), provides the real security value to the application. In fact, some would say the "S" in this acronym stands for "Secure" (while others might say Source).

 

 

All that said, the source IP address is changed when you use SNAT, but the X-FWD-FOR remains the original source address. Simply change your logs to show that parameter instead of SrcIP. Yet another option is using the LTM logging to do whatever security forensics you need to do or transfer this information to a syslog server to analyze. Another option is keeping a single NIC/subnet addressing scheme on your servers and making the default gateway the LTM (using two interfaces and using routes with metrics on Windows as it seems you are describing in your question is a recipe for disaster IMO - or at least a pain to manage).

 

 

In short, getting the source IP to show up in the source IP field of the Windows logs doesn't provide any security benefit, thus isn't likely to be worth the trouble of a server/network reconfiguration or the performance/management headaches that creates.

so that all makes sense. But I am guess where I am stuck is a more simple question I think. If I setup El_jefe's recommendation and setup the gateway of the server to the LTM, what happens during backups, or some other operation that I don't want to go through the LTM? I just remember last time I had to do dual NICs, but that seems to be very clumsy to do. Unfortuantly Mark, the needs of this task for Lync requires the source IP address, it's not just for logging, but for QoS and QoE loggoing for Lync and a few other things. So I guess I have to decide if I want to do the dual NIC and put the second NIC on a separate network or use SNAT and follow this article https://support.f5.com/kb/en-us/solutions/public/4000/800/sol4816.html?sr=29839025. No doubt that using SNAT would be easiest to do but but using two NICS gives me more flexability. But if I understand everything correctly, I just use SNAT and check a checkbox and that should do it.

Let me be even more specific...

 

 

I have been following the article Document Version: 2.8 iApp Version: f5.microsoft_lync_server.2013_03_13. I am using the example.: single BIG-IP LTM (redundant pair) for all internal and external Lync Server services as my topology. My question is about on Page 7 step 3 (Route back to clients or secure network address translation). If I follow those steps, then modify the rules with the link you showed me below, will that work? https://support.f5.com/kb/en-us/solutions/public/4000/800/sol4816.html?sr=29839025

Agreed, I must have mis-read something about "making it more secure...". If you just enable SNAT you don't have to worry about gateways and more than one NIC, just click the SNAT checkbox and that should do it. You still have to change something to get source IP on the server (assuming QoS and QoE can't be changed to look for X-FWD-FOR as well) and looking at a different header is the easiest solution for that

 

As for the traffic not being load balanced. Another falacy here. If you have a single NIC and your default gateway is the LTM, traffic destined for other networks can simply be routed through the LTM, around the LTM using a static route on the server, or in the case of severs on the same subnet, the traffic wouldn't go through the LTM at all. The additional NIC would however, as you noted, give you more flexibility to have none of the traffic go through the LTM and not require static routes on the server, provided the other NIC was on the same subnet as the backup servers for instance in your scenario. Otherwise, you would have to use static routes on either the server(s) or the LTM to route throught the second interface combined with metrics to make sure it uses the NIC on the LTM internal subnet to return load balanced traffic.

 

So doing L3 routing through LTM (given the capacity of most LTM models) is not more costly than throwing an extra switch or L3 router in between the server and the backup devices. Again, this is traffic not destined for a virtual server on the LTM, just forwarded traffic. Since the LTM is not NATing that traffic and just forwarding it, it is not taxing the LTM that much. I'm assuming in all this the primary purpose of the server is running the load balanced application.

 

So, very long answer to your original question short ;-), a.) make LTM the gateway, static route to other network on LTM, and turn off SNAT, b.) use duel NIC with on the LTM subnet and default gateway LTM and second NIC on seperate subnet you need to get to, or one NIC and static route on server to other network, c.) don't change network configuration on server at all, use SNAT and follow the article: https://support.f5.com/kb/en-us/solutions/public/4000/800/sol4816.html?sr=29839025 to get the information you need, assuming Lync QoS/QoE can operate using the X-FWD-FOR header as well.

 

/mh