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?
@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.
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.
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.
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.
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.
we have a playlist of a lot of BIG-IP concepts on youtube called lightboard lessons. 5-12 minutes each that you can forward through for the good stuff that's applicable to you.
Yep! I've seen a few of them. I spent way too much time trying to figure out if you're writing backwards or if there is some behind the scenes magic going on. 😂 It was also through there that I stumbled across another channel that helped me spin up the lab that I have now.
I'm sure I'll have more questions as we roll from lab to production.
Right now I've got round robbin working with basic http connections. The only thing that's kind of "goofy" is how I may get redirectied between web servers and then my request doesn't work quite right. I think it's probably because my "web servers" in the lab are just routers with an http interface enabled, so they serve the webpage and the connection drops just a few seconds later where this wouldn't happen so much in "real life". So, for example, I http://10.1.1.150 (which is my BigIP) and I get connected to "WebServer2" (again, this is just a router with http enabled) I click the "ping" link in the web page presented to me and then I might end up on WebServer3's interface. Then I fill out the "ping" form and hit "go" and if I say on WebServer3 I'm fine but if I get the other 2 servers I'll get an "invalid interface" (because I'm pinging from the interface that's shown in the form which is either the interface for WebServer1, 2, or 3, depening on which page served the form to you). Again, I think the "issue" is on my "WebServer" side and not the BigIP side. One can only simulate real life "so much" in a lab until you have to rely on faith.
make sure you have oneconnect profile enabled on your virtual, it is considered a misconfiguration on http to not have it enabled. Also, if persistence to teh web tier is necessary for your clients, you'll want to add a persist profile as well. Can do cookies so it's passive to BIG-IP, or you can use something like source persistence that will keep a record in memory.
@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
