Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm considering purchasing an F5 load balancing device which will proxy inbound HTTP connections to one of five web servers on my internal network. My assumption was that the F5's external interface would face the Internet and the internal interface would face the internal network where the web servers live. Yet several of the illustrations I'm seeing online place the F5 device behind the firewall This arrangement would cause extra traffic to pass through the firewall and also makes the firewall a single failure point, correct?

What's the rationale behind this configuration?

share|improve this question
Also depending on your config, if the firewall is behind the F5, it can make routing the reverse proxy kinda difficult. Not impossible - but just more aggravating. –  Driftpeasant Dec 1 '11 at 21:58

8 Answers 8

up vote 4 down vote accepted

I think the classical:

Firewall <-> Load Balancer <-> Web Servers <-> ...

is mostly left over from the era of expensive hardware-based firewalls. I've implemented such schemes so they work but makes the whole setup more complicated. To eliminate single points of failure (and e.g. allow upgrades of the firewall) you need to either mesh traffic between 2 firewalls and 2 load balancers (either using layer 2 meshes or proper layer 3 routing).

On public clouds one tends to implement something like:

Load Balancer <-> [ (firewall + web) ] <-layer 2 domain or ipsec/ssl-> [ (firewall + app/db) ]

which is frankly good enough.

  1. If you're using the load balancer to terminate the SSL connection a firewall placed in front of the load balancer only does very basic layer 3 filtering since it's seeing encrypted traffic.
  2. Your F5 already comes with a firewall, which is as good as the filtering rules you put in place.
  3. The defense-in-depth argument is IMHO weak when it comes to layer 3. The attack vectors for web applications are SQL injections, not tripping the firewall to gain root access.
  4. The cores of puny web servers is usually good enough to handle filtering from tcp and up.

Happy to see some discussion on the topic.

share|improve this answer

I'd have thought this would be self-evident: The same reason you put anything behind the firewall.

share|improve this answer

The rationale is to have the firewall protect the web servers. In this case, the point of the load balancers is to make sure the web servers aren't a single point of failure and to balance the load among them. If there's only one firewall, it's accepted as a single point of failure.

share|improve this answer
But aren't the web servers already protected by virtue of being on the internal network? Or are you referring to attacks made under the guise of a legitimate HTTP connection? If the latter... is the firewall even in a position to analyze whether or not any given HTTP connection is a security risk given that the data (in our case) is encrypted via ssl? It seems that only the loadbalancer, not the firewall, would be able to pass judgement one way or the other since it's the endpoint of the SSL connection. It doesn't seem the firewall is adding value in that scenario. –  Chad Decker Dec 1 '11 at 21:57
The web servers are only on the internal network if they're behind a firewall. That's kind of the definition of "internal network". If a device is connected to a load balancer that is connected to the Internet, it's not on an internal network unless the load balancer is also a firewall. (If the load balancer is also a firewall, then it's kind of redundant. Though some people prefer to control everything from one firewall.) –  David Schwartz Dec 1 '11 at 22:01

Normally, you want your load-balancer and web servers in a DMZ (De-Militarized Zone). Access to the DMZ from the internal and external networks should be controlled by the firewall. If the load-balancer is in front of the firewall, it is unable to balance both these loads.

As other have posted, both the firewall and load-balancer will be a single point of failure unless you have redundant equipment.

share|improve this answer

I wouldn't say there's any "extra" traffic travelling through that firewall.

If you have 5,000 requests inbound, and you send an even 1,000 requests to each server, then that's no more requests being serviced by the firewall than if you sent 5,000 requests so the one server, or if you put the firewall behind the F5 (all 5,000 requests still need to pass through that firewall at some point, otherwise they're not on a "private" network at all).

But it is true that the firewall is a single point of failure, but if you're dipping into the budget to fork out to purchase a single F5, well then that F5 becomes a single point of failure as well.

If you're out to configure a fully redundant system, you need two F5's in an active/passive HA cluster, and then you would have two firewalls, also in an active/passive HA cluster.

They may be depicted by a single graphic in the F5's documentation, but that's because it's just showing the logical appearance of the firewall (there's one device serving all the requests), not the physical setup (two devices, one of them in HA standby).

Another reason to put your load balancer behind your edge firewall is because your load balancer may not be web hardened by default (perhaps it has vulnerabilities in its management interfaces, maybe it comes default permit-all, who knows). By putting it behind the firewall and only poking holes for your publically required ports, you run a vastly lower risk of a vulnerable load balancer being exposed to the internet.

share|improve this answer

Quite frankly its to appease security folks that just have to have a separate firewall. The bigip asm module can replace a firewall. combine that with firewall and ipsec policies on the servers and a firewall behind and you have a secure system.

share|improve this answer

Untrust, the inet, only ever touches the firewall, which then only passes specific traffic.

Everything else goes behind the firewall.

That is just how it is done. The firewall is considered 'hard' and safe to expose to untrust. Everything else is considered to in need of shelter...

share|improve this answer

BIG-IP is an ICSA certified firewall. For inbound to the datacenter use cases it can make sense to have the BIG-IP act as a firewall. The BIG-IP platform generally scales much higher than other commercial firewalls and it supports SSL offloading for content inspection. As Jim B mentioned, you can also add the BIG-IP ASM web application firewall for protecting web apps.

High-Performance Application Delivery Firewall



share|improve this answer
Please stop bumping questions that are years old to the front page. Especially ones that already have answers that echo what your answer is. That's what the upvote button is for. Are you an F5 employee, by any chance? –  MDMarra May 31 '13 at 1:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.