We are soon putting our newly purchased BIG-IP 3400's into production is a redundant configuration. I have used Cisco LB's before, and the inside interface where the servers are only supports one subnet. As we are using these LB's in a firewalled and highly secure environment, can we securely use the same LB pair for multiple DMZ's? Regards, Steve

Hi Steve, This is one of those areas where certain camps will say yes it's secure enough and other camps will say "not really". As a former government IT employee, I wouldn't put F5 LTMs on multiple DMZs, simply becasue they are not designed to be firewalls and were designed to bring networks together ala load balancing. Those are my 2 cents and I am sure others will come in with thiers. So I wecome anyone into this discussion.

We have a secure, firewalled hosting environment as well. I am using our BigIPs to do LB on several different applications in several DMZs. What I've done is isolate our BigIPs in their own DMZ and route to the subnets where our load balanced servers sit. I've had no problems with this setup either in terms of security or reliability. It also has the added bonus of making the BigIPs incredibly scalable. The one thing to keep in mind that is different than the Cisco load balancer in that you don't have the distinction of an outside and inside interface. You can have a single interface as the connection point and then just create vlans on the BigIP for your virtual servers. As long as routing is in place, all monitoring, proxying and load balancing can be done via a single interface. Let me know if you want more specific info on our setup and I will give you some tips, pointers and what not. Regards, Jacob

Steve, The short answer is yes, you can make this a secure solution. You will need to properly configure your VLANs and routing on your firewall and your VLANs, routing, and network forwarding Virtual Servers on your LTM to ensure that traffic from one DMZ routes back up to the firewall instead of directly via the LTM. Chris

Hi everyone, I'm new to the f5 scene, as this post will make obvious, and have searched for an answer to my question for a couple of hours before tagging this question onto a likely thread: sorry if it's misplaced. Tacking onto the above: we have a cluster of BIG-IP 6400s which have multiple VLANs on a single internal interface. The problem is that the boxes were purchased and set up with the VLANs "sold" as DMZs. Unfortunately the f5s route between the so called DMZs via the trunk interface, therefore making the whole setup unsafe. We are considering purchasing firewalls to put behind the f5s to separate the VLANs, which seems a little expensive. Thus to my question: is there an easy configuration which switches off all routing between VLANS on the same internal interface of the f5? If there is a more complicated way, could someone give me a pointer so that I can go and talk to our networkers (me, I'm just a project manager, so the answer I received that there's no way to switch of the routing or limit it simply stands unless I receive information to qualify it). As far as the boxes go, I'm pretty pleased with the result, but the possible purchase of additional firewalls certainly questions the economic viability of investing in further boxes. Best regards and thanks for all suggestions in advance les

I'll try and roll some feedback up in a way that will contribute to both questions in this thread. I'll not get into the "what is secure?" question, as this really depends on organizational/business policy at the end of the day. There are a couple of general configuration ideas that will hopefully help. First, a couple of points to address: 1) Does BigIP always route between multiple VLANS? No - this is a common misunderstanding. You can bind your configuration objects to specific VLANS to allow specific traffic flows. 2) Do I need to have a default route on the BigIP? No. BigIP has a feature called auto-lasthop that maps a request back out the same path as it came in. This can be extremely useful for scenarios like this. 3) Can I have multiple routes on the BigIP? Yes, using gateway pools. These three ideas combined can create some pretty flexible and powerful architectures, and it's an extremely useful design pattern to get familiar with. Here's a hypothetical example that will hopefully help clarify a potential use: -- You have 2 different segments for your virtual servers, on different IP blocks. We'll call these virtual servers VS_A and VS_B. -- You've got 2 different VLANS with servers in them. You don't want servers in VLAN A to talk to VLAN B, and you want these servers to go out different gateways (assuming you want to grant them outbound access). Here's One Way to Do It (assuming your vlans are all set up etc): Inbound traffic: -- Create your server pools for VLAN A and B. -- Create your virtual servers on their respective networks and bind them to specific vlans: VS_A binds to VLAN A, and VS_B binds to VLAN B. -- The VLAN bindings prevent hopping vlans through the box, and auto-lasthop will ensure that response traffic goes back out the same path it came in on. Outbound traffic (originating from the servers): -- Create two pools: one with VLAN A's gateway address, and one with VLAN B's gateway address. -- Create two "wildcard forwarding" virtual servers. Bind one 0.0.0.0 virtual server to VLAN A gateway pool A, the other 0.0.0.0 to VLAN B, gateway pool B. The nice bit here is that the gateways for VLAN A and B could be an upstream firewall with access policies, etc. - whatever fits your environment. So now you've got your major traffic flows covered and their paths enforced. Very handy! Hope it helps. -Matt

Using same LB for servers on multiple subnets

24 Replies

cybershoe
Nimbostratus
Apr 20, 2015
Kevin,

With a Forwarding virtual server, BIG-IP will use its routing table to find the next hop for incoming traffic. All Forwarding (IP) virtual servers in the same route domain will use the same routing table, including default gateway (or gateway pool). Putting your forwarding VS on a VLAN in its own route domain would let you specify a different default gateway for traffic ingressing into that RD.

A "Transparent" virtual server is a Standard Network virtual server, with the "Address Translation" option unchecked. Your pool would contain the IP address(es) of your next-hop routers. With a transparent virtual server, BIG-IP will load balance that flow to the L2 address of your router, but leave the L3 address intact. It's essentially outbound ISP load balancing, but with a single next-hop pool member.

Either route domains or a transparent virtual server will let you achieve what you're looking to do.

Cheers,

Adam
nitass
Employee
Apr 20, 2015
Is Josh correct in that you set the gateway pool under the "Last Hop"? And what is a "normal" virtual server. I assume Matt means a "Forwarding IP" VS

what L4L7 means is to create performance layer4 virtual server (not ip forwarding virtual server).

LTM: Per-VLAN Default Gateways by Deb Allen

https://devcentral.f5.com/articles/ltm-per-vlan-default-gateways
David_Martin
Nimbostratus
Apr 20, 2015
Adam and L4L7 are ok.

Just a brief basic summary.

Forwarding ip VS with destination 0.0.0.0/0, All protocols, enabled on vlan INSIDE. It will forward all incoming traffic on vlan INSIDE using bigip routing table. It is the bigip default gateway

ForwardingL4 VS with destination 0.0.0.0/0, All protocols, enabled on vlan INSIDE. It will forward incoming traffic on vlan INSIDE using a pool of gateways configured in the virtual server. With this type of VS you can create one pool per gateway and forward traffic changing the pool.

Note: Be aware, With forwardingL4 BS you can set up a pool with many different gateways and have an automatic outgoing load balance of traffic but you should think on things like SNAT or session persistence to make it work correctly.
dragonflymr
Cirrostratus
Apr 20, 2015
Hi,

Correct me if I am wrong (still figuring out those F5 stuff :-).

Wildcard PerformanceL4 VS on INTERNAL VLAN is ONLY necessary for handling traffic originating from servers on this VLAN (so connections from servers to Internet or other servers on LTM or behind LTM). They are not required at all for traffic coming from other VLANs via VS to servers on INTERNAL VLAN. That part is entirely managed by those VS.

Returning traffic from servers on INTERNAL is directed to LTM either by setting it's selfIP (floating for HA) on servers siting in INTERNAL as def gateway or by setting SNAT in the configuration of VS. SNAT set at VS level is not GLOBAL (opposite to SNAT defined as SNAT object - Local Traffic ›› Address Translation : SNAT List, but even this SNAt object can be limited to given VLAN or VLANs). It's only working for traffic passing given VS, that way source IP of traffic send from LTM is changed from some external IP to the IP of the subnet when internal servers are located, then it can be routed back to LTM without changing def gateway on servers.

Routing of this outgoing traffic is handled (most often) by Auto Last Hop of VS that is processing incoming traffic (so it memorizes MAC last hop and VLAN from which incoming packet was received and send reply using same MAC and VLAN). To create redundancy (or to solve some upstream devices issues) Last Hop Pool can be used instead, then pool of upstream devices can be set for redundancy (be aware - at least according to my test - Last Hop Pool is used ONLY for handling responses from serves to incoming traffic processed by VS, not for outgoing traffic initiated by internal servers).

If it's necessary to allow internal servers to access resources on Internet or outside of servers subnet then you can use: Wildcard PerformanceL4 (could be as well Standard) VS - then for each different pool of upstream devices can be used. If I am not wrong as long as each such VS is enabled on different VLAN you can create as many of them as you have VLANs to be served. Sometimes SNAT will be used, to source outgoing traffic from LTM external IP (it depends I guess on upstream devices) Wildcard servers can be very wide (All ports, All protocols) but can be as well more precise, i.e only UDP port 53 - to allow DNS traffic. That way different kinds of traffic can be routed and processed separately. So I guess those are much better option.

ForwardingIP VS - if all decisions about directing outgoing traffic should be based on LTMs routing table. I think it's not very sophisticated solution but sometimes enough.

SNAT object - then there is little control about anything except origin IPs and translation IPs (OK, VLAN enablement as well)

NAT - but only on per server basis (1 to 1 relationship between origin and NAT address)

If much stricter separation of traffic is necessary Route Domains can be created. With given settings traffic between different RD can be completely separated (Strict Isolation, Parent Name: None) with separate default gateways or even allowing to use exactly same IPs for more than one object (so VS in one RD can have the same IP as in different RD).

So again

for traffic incoming to servers in internal no wildcard servers are necessary
those are only necessary for traffic initiated by internal servers.
VS and SNAT objects can be enabled on VLAN/s so they will only accept traffic from given VLAN - blocking inter VLAN communication
RDs can be used to completely separate network configs on one device.

Well, hope it make sens and I avoided any serious mistakes here

Piotr

Forum Discussion

Using same LB for servers on multiple subnets

24 Replies

Recent Discussions

Maximum throughput of f5 ltm

Issue on license renewal

iRule cookie persistence and pool redirect

redirect not working

Access azure app service using f5 LTM

Related Content

Multiple server with one VS

Remove subnet from NAT pools without any impact

Multiple Kubernetes Clusters and Path-Based Routing with F5 Distributed Cloud

F5 Distributed Cloud Origin Server Subset Rules

Configuring Pool members in a separate subnet of self IP on a Virtual Server