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?

  • 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

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.

  • A simple transparent firewall in front of the F5 can do protocol validation and protect the F5 from any direct attack (such as an attempt to exploit a weakness in the F5 IP stack). This model adds little complexity as there is no mesh or routing protocol involved. – Roy Oct 16 '17 at 16:12

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


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.


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.

  • 1
    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
  • 3
    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
  • The primary function of the firewall described here would be to protect the ADC which in turn protects the web servers, in many ways as a firewall would, but with the added benefit of also being a load balancing reverse proxy with traffic management and having the additional features of a web application firewall. – Roy Sep 10 '15 at 5:03

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.


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.


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...


It is common to view security implementations as a set of individual layers of security, often referred to as the layered security model.

In the simplest of terms, each layer of security that must be traversed contributes additional resistance against penetration - each layer increasing the total difficulty at which an attacker may gain unauthorized access.

To me it always seemed quite sensible to have detection, prevention and filtering abilities on the Internet edge, for any number of reasons - and in the context of layered security I think it makes perfect sense to have a packet inspecting firewall as your first line of defense - such a device has the added bonus of being able to defend against attacks targeted at the ADC or other Internet facing network equipment.

As an example to illustrate my point; Consider how an outer (edge) firewall is well placed to verify protocol conformance before traffic is allowed to enter your network, that is before it can be passed to potentially vulnerable devices. The firewall could also look for variations and patterns in traffic that conform to technical specifications but deviate from typical use or common pratice - this increases the chance of discovering concealed data streams, attempts to bypass checkpoints or even new facilities for request smuggling.

A typical, though somewhat simplified, Web/SaaS design might look something like:

  1. Public Internet
  2. SPI Firewall (Cisco ASA, Fortigate)
  3. Load Balancer/ADC/WAF ** SSL/TLS term. point ** (such as Big-IP, Baracuda)
  4. Next Generation Firewall (such as PaloAlto, CheckPoint)
  5. Web Application Services
  6. Port-based Firewall (such as a low-end Cisco ASA or even iptables)
  7. Database and Storage Services

Redundancy can be added to each individual component as required.

Personally I prefer local redundancy for firewalls (eg. 2 nodes per firewall per site) even if the load balancers are deployed for global high availability or site failover (requires only one Big-IP per site).


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



  • 4
    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
  • While the application delivery controllers from F5 are capable of extending basic protection to the associated web servers, few think of them as a fully capable firewalls and fewer still would expect it to be able to protect itself to any significant degree. In other words, the built in firewall can in some cases replace the typical inner firewall, that is behind BigIP, facing the web servers. It cannot replace the typical outer firewall, that is the one in front of the BigIP, facing Internet. – Roy Sep 10 '15 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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