I often have discussions with people who want to deploy their firewalls in Layer 2 mode. This isn’t a decision to take lightly and needs a lot of careful planning.
Here are my notes both for and against Layer 2 Firewalls. Keep in mind that L2 Firewalls are most common in data centres and are typically retrofitted to provide security.
In general terms, I would only recommend using L3 firewalls for any new design or new build.
| Reason | Explanation |
|---|---|
| No change to existing IP addressing or Servers | This is the most common reason. You have a legacy infrastructure that you need to add new firewalls without changing IP addresses |
| Routing protocols can establish adjacencies through the firewall | Passing OSPF neighbours through a firewall is possible but a “bad idea”™ |
| Protocols such as HSRP, VRRP, GLBP can pass | For certain designs and requirements, you might even want to do this. |
| Multicast streams can traverse the firewall | A major reason. Most firewalls are “feature incomplete” when it comes to Multicast and cause much pain in deployment |
| Non-IP traffic can be allowed (IPX, MPLS, BPDUs) | There is still legacy traffic (in the data centre especially) and you may be firewalling IP but passing legacy traffic. |
| Reason | Explanation |
|---|---|
| No visibility makes it hard to troubleshoot | Troubleshooting a L3 network is much easier since each step of the path is known |
| Layer 2 Firewalls are hard to detect | This isn’t a good reason. Security by obscurity is false security. If you need to obscure your security controls then you have a deficiency in your security process |
| Can easily insert loops into networks | Strong design and implementation discipline is necessary |
| Only allows for two interfaces, inside and outside (no DMZ interfaces) | Enforced design limitation may be functionally incomplete or need more firewall instances |
| NO dynamic routing protocol support or VPN support | The firewall control plane cannot insert itself into the IP circuit and cannot provide a lot of services |
| Specific design limitations | Most Layer 2 implementation lose a lot of features. Often unexpected features like QoS, VPN or GRE tunnels. You will need to research very carefully |
| Dual Homed Devices can creates L2 Path defects | Dual homed servers using active/standby are OK, but Active/Active can cause of lot of pain ( MLAG can help) |
The EtherealMind View
As a general rule, I would not deploy Layer 2 Firewalls in a network. The negative aspects outweigh the positive features as a general topic. There are times when nothing else will do and a L2 solution is the only way. Just be careful to use your knowledge of first principles to consider the design you need to use, and then test it. You don’t want to find out what the real problems are after you have completed the deployment.
I imagine that many people will have different views. Lets hear them and I’ll try to respond.
About Greg Ferro
This is an extremely relevant post to Cisco data center ‘network’ engineers.
Thanks so much putting thoughts to paper on this. It is very much appreciated and I expect to share this with all of my coworkers.
-One more caveat against transparent load balancers, cisco wise anyway, is the limitation in most OS revisions for multi-context.
What about those pesky transparent load balancers out there? same post but replace the word firewall with load balancer?
Great write up!
What about OS built-in firewalls such the one in Windows or Linux? Do you consider them as transparent L2 firewall? If not how would you categorize them?
Thx,
Didier
1. They are firewalls ( actually, packet filters or non-stateful inspection).
2. They don’t usually impact the network design i.e. I would argue they are not L2 firewalls since they apply to the “network adapter”
3. Tools to manage large numbers of firewalls are a big problem.
IPTables is stateful, but you have to configure it properly. Basically, have a line that evaluates “state RELATED,ESTABLISHED” and “state NEW” for all of your rules.
Also the kernel modules have to be built with conntrack enabled.
I think that you must deploy l2 or l3 Firewall in base of what you have to do… it doesn’t exists a “better” way, but some times you need routing, DMZ and you must deploy l3 Firewall, some times, instead, you need transparent Firewalling and you are OK with only Trust and Untrust zone.
I use both ways, tipically l2 in our little peripheral MPLS Nodes, l3 in our bigger MPLS Nodes and for some of the internal buildings…
Regards “No change to existing IP addressing or Servers”, some times I use a lot of NAT/PAT…
Transparent mode firewalls=nightmare! We recently introduced some to meet “compliance” requirements and it broke BGP MD5 checksums. What a pain.
ASA’s used to (still do?) require a custom TCP map to permit TCP MD5 for BGP.
With regards to some of your stated limitations though, you *can* run an FWSM in “mixed mode” and ASAs will support this with a new code release in July. That means you could have one layer-3 context and another layer-2 context. We do this (unfortunately) all the time.
I can only agree with you Greg. Every time I’ve had to work with L2 firewalls has been a nightmare… (luckily not that often)
Great post. I’ve used some L2 firewalls in situations for Layer8/9 reasons. For example, Security team would like to implement IPS but Network team manages internal firewalls to business partners. By keeping them separate, Security gets what it wants without ruffling Network team’s feathers too much. Also enables long-term transition L3 at some point. By no means the best case, but it happens. Troubleshooting can be difficult (as you mention), leading to finger-pointing.
I totally agree with the idea that Layer 2 firewalls should be avoided, if possible.
Two more reasons:
1) layer 2 firewalls (especially when deployed in pairs) behave like “broken cables” (cables that don’t pass traffic by default) between VLANs/switches. BPDUs need to be allowed through, otherwise STP will not work as expected. The last thing an engineer needs during a layer 2 meltdown is to worry about the firewalls possibly causing loops
2) it offers more chances of screw-ups. From a layer 3 point of view the inside and outside firewall interfaces are in the same network. I have seen more than a few examples when less experienced team members attached the server ports to the “inside” VLAN instead of the “outside VLAN” (behind the firewall). The server worked, and nobody caught the mistake for years. With a layer 3 firewall the outside firewall VLAN is behind the firewall for sure.
What about Layer 1 Greg? Palo has VirtualWire (L1) mode that is great for transitional use cases.
I’m curious, is there an architectural objection to layer 2 firewalls or is this more of a comment on a particular vendor’s implementation? Making a firewall part of a spanning-tree domain sounds like a bad idea, but I’m not sure I understand why OSPF shouldn’t be run through a firewall.
Another thing I haven’t come in contact with during my years in the industry is someone who likes to do network documentation
while the ASA/FWSM not supporting PBR ,in some case you need L2 firewall for security control and a L3 switch (for example SVI on C6500) for PBR.