I'm currently analyzing the consequences of multipath connections for the firewalls. In that context, I'm wondering if it's really uncommon to have several firewalls at the borders of a network to protect it. The typical case I'd imagine would be a multihomed network, for which the administrator would have different policies for links from different (or not) ISPs. Or maybe even in an ISP's network.

What would be the practical (dis)advantages of such a configuration? Could you provide an example of an existing topology using several border firewalls?

EDIT: In particular, I'm interested in the configurations where one internal end-host could use any of the firewall's paths. The configuration's purpose would not be to isolate internal zones one from another. Actually, my goal is to see how the firewalls can influence protocols that might use multiple paths (at the same time) to work correctly.

  • Why not just use a firewall cluster and BGP/routers to handle the dual Internet connections? – Paul Ackerman Dec 19 '12 at 15:43
  • Yes, why not? That's kind of the question... – nimai Dec 20 '12 at 1:17

Multiple firewalls are a good idea in several cases.

Internet connection shared between office-use and webapp

Less common in these cloudy days, but take the case of a webapp being hosted out of a private datacenter, sited in the company office. If one of the workstations in the company office gets wormed (to use an ancient example) by Slammer, all of that traffic will be egressing through the shared internet connection.

If there is a single firewall protecting both the profit-making webapp and the company "browse over lunch" network, such flagrant network abuse as Slammer can cause a DoS on the firewall. This creates a network-down event for the for-profit web-site.

If two firewalls are used, one around the webapp zone and a second one for corporate internet stuff, the office firewall would DoS itself while the webapp merrily continues earning money.

Secondly, such a firewall can provide protection from internal threats; though that could be done with a sufficiently advanced monolithic firewall as well.

Benefits: Fundamental fault isolation between zones

Multi-homed network: Internet + private network

In this case there are more than one connections, an Internet connection and a private network. The private network may be a physical layer connection, or it could be a VPN tunnel to something like an Amazon VPC.

It is entirely possible that the private network connection, whatever it is, can't terminate at the one firewall a company has. For instance, Amazon VPC connections have some specific requirements that may trigger a hardware purchase. Or maybe the one firewall can only have one external connection and adding a second slightly-more-trusted external connection isn't in its feature-set. In these cases, an additional firewall can help terminate and protect the added network connection.

Benefits: Provides capability not present in original device, physical network isolation between trust zones.

Multi-homed network: multiple Internet connections

This is the same setup as the first case, but the Office internet has it's own connection to the world.

In this case it is entirely possible that the Office Internet connection terminates in the downtown office, where the webapp connection terminates in the rented datacenter out in the suburbs. The physical separation makes two devices an easy choice. There may be a physical connection between the datacenter and the office, or there may be a site-to-site VPN.

In either case, multiple firewalls make a lot of sense.

Additionally, if the office ISP is something slow like Comcast Business while the datacenter ISP is something really fast with an SLA, the datacenter connection will need beefier firewalls to keep up with all that traffic.

Benefits: Enhanced network isolation between zones, ability to terminate site-to-site VPN connections between datacenter and office

Anycast to a single site

This is a rather specialist case, but the only way I can conceive of to do the case you're thinking of. In this case, anycast is used to set up multiple points on the Internet connected with very fast network connections to a central site. The higher level protocol is TCP based.

In this case, firewalls would exist at the perimeter of each anycast entry point to the company network. The multi-path case would require:

  • The end point to change network location enough to cause it to change anycast destination (pop switch).
  • The end point to not change it's IP address.

In this case traffic would enter on one leg and likely leave down the same leg, or exit wherever the routing tables say to send the replies. After the pop switch traffic would come in through a different leg, but replies would likely stay the same (unless routing tables have changed).

The tricky part here is that the firewall in front of the second leg would not see the connection setup so it wouldn't know about it. If it's a statefull firewall, chances are very high it'll reject it out of hand. A stateless firewall would pass the traffic though.


In this case multiple sites are run using GeoIP to bring services closer to clients.

To get the case you're thinking of:

  • An end-user has to change geographic location enough that the GeoIP service returns a different IP.
  • The end-user creates a new TCP connection for each transaction of the higher level protocol.

This is the easiest case. It's just new TCP connections, and the firewalls in front of each GeoIP site would treat each connection like a new connection and allow it. The presumably same server providing services would see each as a new TCP connection and handle it appropriately. In a setup like this, Source NAT would be used on the GeoIP site firewalls to ensure replies are sent down the right leg. No muss, no fuss.

Whether or not the higher level protocol can handle such connections is up to the higher level protocol. That isn't a firewall issue at all. Unless, of course, the firewall is stateful in that particular protocol, at which point a setup like this would fail whenever a flap like this happens.

  • Thank you for that long and enlightening answer. I realize I might not have been very clear in my question, which I've just updated a bit. However, I believe you answer it partially. – nimai Dec 19 '12 at 14:37
  • @nimai If I'm reading your revision right, you're wondering how a multi-firewall environment would work for TCP connections (an IP:port <--> IP:port pair) that traverse multiple paths. Is that it? – sysadmin1138 Dec 19 '12 at 14:55
  • Yes. The point is that those TCP connections would be part of an higher-layer connection for example. – nimai Dec 19 '12 at 15:03
  • I'm impressed by your devotion and imagination! Thank you again. For completeness, I think I've found another simple case: A network providing to its users both an IPv4 and an IPv6 accesses. A firewall would handle the IPv4 trafic, and the other the IPv6... only because of compatibility issues. I think that's a good example of common configuration that could be used by anyone and that justifies the multipath-related concern. – nimai Dec 20 '12 at 1:25

There may be a value in having several firewalls. Especially if they are handling very different tasks. It may be easier to check logs and discover suspicious network traffic.

One could compare it with a ordinary grocery store. You have one entrance for emplyoees only, high security and all activity is logged. Then you have the main entrance which is open for everyone, no security and no or very little logging.

However, it all comes down to network design. It might or might not be useful with two separate firewalls. The netork I'm administrating we DO have one separate firewall for each access point because the security levels of our networks range from open to "top secret" and trying to get one single firewall handling all that at the same time would be a nightmare.

  • So in this case, if a connection between 2 hosts is established using the path of the first firewall, no connection will ever be established through the second firewall? – nimai Dec 19 '12 at 11:35
  • Nimai - no, not at all - it has nothing to do with "firewalls", it has to do with routes. If the routing changes (which could be due to a link going down, or getting too much traffic and changing a weighted route), a connection could go through a different firewall. Probably not the best practice, but it could happen. – mfinni Dec 19 '12 at 13:58

We use debian for all our customers and multi home the gateway and use IPTABLES to lock down traffic. You might think this is a bit of a hand crank but I know this is used widely in the industry I work in. With IPTABLES, you can really go to town on what traffic flow you can allow. However the problem is that it may have connection limit and throughput issues. Bonding nics on the server may help. So advanatges is that it is cheap and fairly powerful but disadvantages are that you might find bottlenecks in the amount of connections the linux box can handle. Check this -iptables-rules-examples- really helpful in how to set explicit firewall rules using IPTABLES. Additionally you can use vrf and HA the gateway - this is all available in CentOS 6.3 -centos6.3 HA

  • 1
    So you have a single entry point controlled by a single firewall? The question is about having several firewalls, one for each entry point for example. I'm not sure I visualize your topology very well... – nimai Dec 19 '12 at 10:59
  • Because he said VRF and HA, he's talking about multiple firewalls, but not in the way that I think that you mean. – mfinni Dec 19 '12 at 13:55
  • 1
    We do use multiple linux routers and have firewall routes. Some linux routers are in HA. The product we use is Cloudstack and we have 1000s of customers doing it this way – Oli Dec 19 '12 at 22:19
  • Ok, I didn't know what HA routers were, now it's clearer. Thank you. – nimai Dec 20 '12 at 1:30

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