Forum Discussion

irbk's avatar
irbk
Icon for Cirrus rankCirrus
Aug 17, 2023

Using 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 (10.1.1.0).  Everything is set up and a client on the 192.1.100.0 network can reach the 3 servers I have set up behind the BigIP on the 10.1.1.0 network and the BigIP is doing RoundRobbin load balancing just like I have it set up.  So now that I've got the lab working, I need to get a more "real life" scenario running. 

In production, we arn't going to use the BigIP for any "external traffic".  Only clients on the 10.1.1.0 network will be reaching out to the servers I want load balanced.  I tried creating an additional virtual server on the 10.1.1.0 network that pointed to the same pool as as the original virtual server (which I know works) so I'd expect it to work.  While I can ping the new 10.1.1.0 virtual server, when I try to browse to it I can't get to it.  

How do I go about setting up a virtual server for load balancing client requests for servers when the clients and servers are on the same subnet?

Thanks in advance!

  • 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.

  • irbk's avatar
    irbk
    Aug 17, 2023

    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. 

  • For 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.  

    • 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.

      • irbk's avatar
        irbk
        Icon for Cirrus rankCirrus

        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. 

  • irbk - If your post was solved it would be helpful to the community to select *Accept As Solution*. 
    You can select more than one if you like - it seems there have been a few progressive "solutions" here. 😄

    This helps future readers find answers more quickly and confirms the efforts of those who helped.
    Thanks for being part of our community.
    Lief