Is it possible for an F5 to load balance traffic to pool members in a network segment if it doesn't have a self-IP in that network segment?
**Please refer to the diagram attached***
To give you more context, I have a virtual server configured with a DMZ IP(172.16.1.10) and I want it to load balance across servers in my inside/trusted network (10.0.0.22 & 10.0.0.23). If the F5 doesn't have a self-IP in the 10.0.0.0 network, is it able to load balance across the pool members?
If I have a self-IP in a different network, say 10.0.1.1 network and I create a rule in the firewall to allow traffic from that IP to the pool members, is that sufficient?
Yep that'll work just fine. You can load balance to anything reachable from BIG-IP, and if wanting symmetric traffic delivery for ingress and egress, that the servers have routes back to BIG-IP. Just be aware that edge FW is going to be doing a lot of transit work.
Yes you can. The trick is the BIG-IP instance needs to have network routes to tell it how to get to those servers that are not in one of its networks. So you could have a network route that says 10.0.0.1/24 goes via 10.0.1.1 network.
26-Aug-2022 09:16 - edited 26-Aug-2022 09:19
I would also point that in your design you'll very likely need to use Source NAT in the Virtual Server.
That may introduce some issues regarding original client IP information loss (it would disappear from L3 headers). In HTTP traffic this is usually circumvented using the X-Forwarded-For header, but if you can use any similar technique really depends on the protocol in question.
The preferred design is getting your F5 box between the router and the servers, and making F5 the default gateway of said servers. This would ensure that return traffic will always get through F5, and a clean routing design doesn't need "tricks" like Source NAT or PBR.
Just a little gentle pushback...the preferred design should always comes down to each company's business, security, and operational requirements. What works for you or for me isn't the best path for others. The great thing is all of the choices here work, work well, and are supported configurations, with obvious tradeoffs that need to be considered.
And the great thing about BIG-IP is that you have granular options to route or SNAT I've seen folks move to BIG-IP just because their previous platforms were all or nothing!
Indeed. 😊 If it works, it works.
If given the chance I'll always go for routed design over one-arm. But besides being a "personal" preference, I mentioned the routed design because it is a way to avoid source NAT. Knowing the full details about the application you want to serve is the key.
No doubt! I also prefer routed over one-arm for various reasons. I also prefer to segment DMZ vertically instead of hopping back and forth through same gear, and horizontally to isolate ingress and egress traffic (as it relates to whether the source is external or internal) but not everyone has the budget or greenfield options to accomplish that.
29-Aug-2022 08:59 - edited 30-Aug-2022 05:55
Yes that is how it is intended to be.
Just set the routes to your inside network like 10.0.0.0/8 to the gateway on your inside interface and the default 0.0.0.0 to your outside interface 172.16.1.XY (Gateway). In our setup we have two connections between firewall and f5 thats outside and inside and with that routes ur good to go
Lots of answer, i'll add mine to the mix as well.
When implementing the F5, I made sure the F5 had an interface all the destination pools vlans. But I wasn't ready to make it the DGW for everything, so I have SNAT and implemented XFF header
My thoughts where.
I have a PA out the front that routes to the F5 (yes I know I could place it out front but). If I want I decrypt and inspect traffic on the inboud by the PA, but the F5 has ASM and WAF as needed.
I could if I wanted to push F5 -> pool server via the PA - and have designed to allow that for some occassions - for the front end servers, that way I can get F5 ASM and PaloAlto Security looking at the traffic. Not in place by default because of the latency vs the threat. But its there if needed.
Common design as well! Good to keep in mind for Virtual Edition deployments where the licensing is by throughput, also.