Forum Discussion
irbk
Cirrus
CirrusUsing F5 for load balancing internal traffic
We recently purchased F5 but I'm implmenting it in a lab before production. In my lab I have a "external" network (192.1.100.0), the "management" network (192.168.1.0), and the "internal" network (1...
irbk That is great that you figured out the solution but I would like to mention a few things so you do not set yourself up for failure.
1. Unless absolutely necessary I would avoid using Auto Map and instead create a snatpool and use the same IP as the Virtual Server you have created and use that snatpool instead of Auto Map. The reason for this is if you find yourself in a situation where you have a virtual server/s that has a significant amount of connections your health monitors and a few other things could stop functioning because you will have exhausted all the ephemeral ports on the F5s self-IP which is what is used for Auto Map.
2. The reason the F5 requires SNAT to be configured for your situation is because when traffic traverses the F5 from one interface to another and that traffic has to pass through the F5 the F5 will automatically stitch the two connections together while allowing the server to see the original client IP. Your configuration for internal is necessary because the client, one of the other devices in the same subnet as the pool members, can be seen by the destination pool members so instead of the pool members responding back through the already formed TCP connection through the F5 they will go directly to the client since they know its IP which breaks the TCP connection previously formed through the F5. With SNAT enabled the pool members only see the F5 as the source of the connection so the pool members have to respond back to the F5 which then allows the F5 to stitch the client side and server side connections together.
3. If you require tracking of the true client in a SNAT configuration and the traffic is only HTTP or HTTPS and you are decrypting at the F5 and you have an HTTP profile you can enable X-Forwarded-For header field insertion using an iRule, traffic policy, or the easiest way of using an HTTP profile. The X-Forwarded-For header field will be inserted into the HTTP header and a value of the original client IP will be stored as the value of that HTTP header field. You can then configured your pool members to search and record the value of that header for tracking purposes.
Thanks for the reply. I'd rather use a better known solution than mine anyway, considering I have all of about 6ish hours of knowledge with BigIP. I just started spinning up the lab yesterday and I am fully aware there is a whole lot about the system I don't know. So I'll totally set up a snatpool using the same IP as my virtual server and swtich over from auto map to snat!
As for your #2 that totally explains why in a wireshark I'd see a bunch of retransmits and eventually everyone just says "yeah, I'm done" and the connection is dropped. Thanks for the explination!
As for 3# as I said, I have perhaps 6ish hours of BigIP knowledge and I don't understand most of what you said but I'm sure it was helpful to someone else... or perhaps me several months from now.
Thanks again! I'm going to go see if I can figure out how to set up that snatpool.
irbkCirrus
CirrusFor anyone else that may stumble across this, cause it wasn't easy to find, this is so simple. For the "internal" network, set the vserver up exactly like the original working one, except turn "Source Address Translation" from "none" to "Auto Map". Why you DON'T have Source Address Translation turned on for External<>Internal but need it turned on for Internal<>Internal is beyond my level of F5 understanding. However, it's that easy.
Paulius
MVP
MVPirbk That is great that you figured out the solution but I would like to mention a few things so you do not set yourself up for failure.
1. Unless absolutely necessary I would avoid using Auto Map and instead create a snatpool and use the same IP as the Virtual Server you have created and use that snatpool instead of Auto Map. The reason for this is if you find yourself in a situation where you have a virtual server/s that has a significant amount of connections your health monitors and a few other things could stop functioning because you will have exhausted all the ephemeral ports on the F5s self-IP which is what is used for Auto Map.
2. The reason the F5 requires SNAT to be configured for your situation is because when traffic traverses the F5 from one interface to another and that traffic has to pass through the F5 the F5 will automatically stitch the two connections together while allowing the server to see the original client IP. Your configuration for internal is necessary because the client, one of the other devices in the same subnet as the pool members, can be seen by the destination pool members so instead of the pool members responding back through the already formed TCP connection through the F5 they will go directly to the client since they know its IP which breaks the TCP connection previously formed through the F5. With SNAT enabled the pool members only see the F5 as the source of the connection so the pool members have to respond back to the F5 which then allows the F5 to stitch the client side and server side connections together.
3. If you require tracking of the true client in a SNAT configuration and the traffic is only HTTP or HTTPS and you are decrypting at the F5 and you have an HTTP profile you can enable X-Forwarded-For header field insertion using an iRule, traffic policy, or the easiest way of using an HTTP profile. The X-Forwarded-For header field will be inserted into the HTTP header and a value of the original client IP will be stored as the value of that HTTP header field. You can then configured your pool members to search and record the value of that header for tracking purposes.
- irbk
Thanks for the reply. I'd rather use a better known solution than mine anyway, considering I have all of about 6ish hours of knowledge with BigIP. I just started spinning up the lab yesterday and I am fully aware there is a whole lot about the system I don't know. So I'll totally set up a snatpool using the same IP as my virtual server and swtich over from auto map to snat!
As for your #2 that totally explains why in a wireshark I'd see a bunch of retransmits and eventually everyone just says "yeah, I'm done" and the connection is dropped. Thanks for the explination!
As for 3# as I said, I have perhaps 6ish hours of BigIP knowledge and I don't understand most of what you said but I'm sure it was helpful to someone else... or perhaps me several months from now.
Thanks again! I'm going to go see if I can figure out how to set up that snatpool.
- JRahm
Admin
Hi irbk if you think you'll exceed 64k of connections, that's where port exhaustion will impact snat automap, AND a snatpool with only one address in it. If you don't think you'll get anywhere close to 64k, snat automap is fine, but you'll want to watch your traffic over time. If you want to future proof, the snatpool with at least two addresses to start is the way to go.
Nothing to add on your other questions, Paulius nailed it.
- irbk
Yeah, I've already had that discussion with my boss. Told him the issue with using Auto and said "but were talking about 65,535 connections" so we likely don't have to worry about it when we only have around 150ish users using the servers that will be behind the BigIP.... unless each client manages to open up 437 sessions each.... but also users... and windows.... so anything is possible LOL. We can set up the SNATPool with the single IP and if we ever hit a point where we need it, I'll just add a 2nd IP to the SNATPool.
