What are the reasons to use a firewall in transparent mode?

Solution 1:

The biggest reason I know of? ipv6. A large part of the reason IPv6 was proposed was to get around the address exhaustion problem of IPv4 and get rid of the 'ugly hack' that is nat. Because of the IPv4+NAT combination, far too many people automatically assume that firewall == nat which is not the case. Nearly all firewalls can do NAT, but not all NAT solutions can do firewall.

IPv6 assumes an unmasked network, which causes some problems with people used to everything being masked. In an IPv6 network you are much safer assuming that a 'public' IPv6 address is no guarantee of routeability.

But it's not just IPv6. The university I used to work for had a /16 IPv4 allocation when I worked there. They had desktops with 'public' IP addresses on them. Yet they were still firewalled because our firewalls were working in 'transparent' mode. We had the address space, why not? It also made certain use-cases easier to handle without having to play NAT port-forwarding and public-ip-assignment games.

If your definition of transparent means an L2 security service, the use-cases there are common even in IPv4 networks.

• AWS Security Groups operate like this for their ec2, Virtual Private Cloud, and other services.
• Azure Security Groups operate similarly.
• It's been a while since I worked with it, but I believe VMWare ESX networks had a similar option.

These systems are the core of network security in the major public cloud providers. You define a list of allow/deny rules, and they apply to the resource. In AWS this is the interface of the EC2 instance, Lambda, or other service. The firewall doesn't exist on the box like an iptables, but below the virtual machine. This makes it a transparent L2 device.

Solution 2:

You may have a requirement that some hosts must reside within the same LAN segment and at the same time, they require very different security policies. For example, you may want to be in the same network as your AD domain controllers (DCs), and yet you want to secure them and separate from the rest of the network somehow.

For this, you add a transparent firewall. On one side, you'll have your DCs, on the other side you'll have the rest, and still they may live inside a single network, like 192.168.5.0/24, and think happily they don't have any L3 devices between them. And all of them will have the same default gateway, which will likely be deployed on the "insecure" side.

The other case could be be when it comes to really firewall bridged traffic. E.g., there are services which even don't know what IP, IPv6 or any other L3 is, and they are communicating using raw Ethernet frames. ATA over Ethernet (AoE) first came to mind. I've seen some industrial automation that communicate using raw Ethernet. And when it comes to ascertain the AoE shelfs are accessible to only certain known hosts, you will use something like these "bridge-firewalls".