Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Using same LB for servers on multiple subnets

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
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Matt,

That's a very good explanation of logically slicing up the BIG-IP to separate traffic for multiple customers. It would be great if F5 would add something like this to a solution guide. It comes up frequently and isn't an obvious solution.

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Aaron - as usual, your description is dead on: "logical slicing" of the BigIP. Thanks for pointing it out in that context.

To add to your idea a bit further, this design makes it possible to bind rate classes to these various virtual servers to impose throughput (and resource, by extension) restrictions based on SLAs, customer groups, etc. This allows you to go real far in 'virtualizing' the BigIP itself.

-Matt
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Aaron, Hi Mat,

thanks for the prompt reply - I'll talk to the networkers on Monday.

Have a nice weekend
les
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
This thread (Click here) has a good discussion about similar architecture to what Matt describes as well.

Denny
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
A bit late in this thread.. sorry. Say I already have a pair of 6400's with all virtual servers on one VLAN (lets call it, OUTSIDE) and all back-end servers on another VLAN (INSIDE).

I want to give the F5's the capability to have pool members on a different subnet other than INSIDE's. So, according to Matt, I would set up my VLANS, either on different physical interface or just trunk the existing INSIDE interface to include the new VLAN (INSIDE2). I would then bind the new virtual servers to use INSIDE2 (vlan) only. Without creating any wildcard forwarding virtual servers, will the traffic from INSIDE2 still go out the BigIP's default gateway, or will it be blocked? If I do add a wildcard virtual server for only INSIDE2, will this affect existing outbound traffic on INSIDE?

Sorry, this might be confusing, but I appreciate your input.
Thanks,
Josh
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
All traffic needs a virtual server in order to traverse the BIG-IP, so traffic from INSIDE2 will be blocked until it is added as an enabled vlan to your existing forwarding virtual or you create a new one for it. Keep in mind this carries the potentially unintended consequence of allowing traffic between INSIDE and INSIDE2. If your forwarding virtual is 0.0.0.0/0, and you don't want the traffic between INSIDE and INSIDE2 to occur, you can create more specific virtual servers:

INSIDE/n disabled on INSIDE2
INSIDE2/n disabled on INSIDE
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
I don't currently have any forwarding virtual server, which is why this confuses me. All traffic is going out the BIG-IP's default gateway without the forwarding server.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
You've probably got a default SNAT defined, which actually behaves like a forwarding VS. Traffic sourced from the internal side will be allowed out and will be tagged with the egress self IP address of the BigIP on the way out.
-MC
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Correct.. all of my virtual servers are using the "Auto SNAT" SNAT pool. All traffic is tagged with the floating IP address of the pair.

I would probably continue to use Auto SNAT for the INSIDE2 vlan. However, I would specify at the VS level which VLAN to bind to.. INSIDE or INSIDE2. Do you see this as being a security risk? The VLAN binding should prevent the VLAN's from talking to one another, right?.. although they would be leaving via the same SNAT pool which could pose as a risk?

Thanks again.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Is there a way to bind a pool to a specific VLAN? Or can I only bind the virtual server to a specific VLAN? I realize that binding the Virtual Server prevents them from talking to each other.. but what about the actual servers? Is there any mechanism in place to keep pool members from VLAN1 talking to pool members from VLAN2?

Thanks again!
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
There's not a way to bind pools or servers to a VLAN, but since the LTM is default deny, if you haven't configured a way for the pool members to talk to each other (via a forwarding virtual server or SNAT), then they shouldn't be able to.

Denny
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
OK, thanks for the answer. I guess the most secure way to do things here, is to stop using Auto SNAT, and to configure separate SNAT pools for each VLAN. I see this as the only way to keep servers from both VLAN's going out the floating IP addresses (via Auto Snat), thus preventing chatter. Does this sound reasonable?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Posted By L4L7 on 02/06/2009 7:02 AM
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


You can't assign a normal pool to IP forwarding virtual servers. Should this gateway pool be assigned as the "Last Hop" pool?

Josh
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Good catch. Set it up as a "normal" 0.0.0.0:0 virtual server, and use the fastl4 profile with all protocols selected. Then bind it to your vlan in question and point it to a port 0 pool containing your router's IP address(es).

-Matt
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Old Thread but I'm trying to do the same thing in 11.6 I need to have my forwarding virtual server traffic use a different route for egress traffic.

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

-Kevin

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0