Using same LB for servers on multiple subnets

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

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

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

Hi Aaron, Hi Mat,

 

 

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

 

 

Have a nice weekend

 

les

This thread (Click here) has a good discussion about similar architecture to what Matt describes as well.

 

 

Denny

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