Implementing a Bridging Firewall

Understanding Bridging Firewalls

A bridging firewall sits between two network segments and pretends to be a simple patch cable, yet it inspects every frame that passes through. The classic router sits at the boundary between two networks, translating between them and applying network address translation (NAT) when necessary. In contrast, a bridge forwards frames based on MAC addresses, keeping the two sides of the network unaware that a device is in the middle. When the bridge is augmented with filtering logic, it becomes a firewall that can block or allow traffic without the need to re‑configure the devices on either side.

The distinction between a traditional firewall and a bridging firewall matters when you have an existing network that cannot be easily changed. Traditional firewalls usually act as the default gateway for internal hosts, which requires each host to know the firewall’s IP address. That setup forces you to modify host routing tables or change DHCP scopes. A bridging firewall removes that requirement; hosts keep their existing default gateway, and the bridge simply slides into the physical topology, filtering traffic as it moves between segments.

In practice, the bridge listens on two network interfaces. When it receives a frame, it looks up the destination MAC address in its internal forwarding table. If the MAC belongs to an interface on the same side, the bridge forwards the frame back out that same interface. If the MAC belongs to a different side, the frame is sent out the other interface. The firewall logic inspects the frame’s payload – usually an IP packet – and decides whether to allow or drop it before it crosses the bridge.

Because the bridge is transparent, the IP stack on both sides of the bridge sees no change. From the perspective of an external router, the bridge disappears; only the IP addresses and routes on the internal hosts matter. From the perspective of the internal hosts, the bridge is just another link. This transparency lets you apply advanced firewall rules without touching host configurations or dealing with NAT quirks.

To set up a bridging firewall you need a Linux box that can run the bridge code and the iptables firewall engine. Modern kernels expose bridge support in the kernel, but they do not automatically pass bridged packets through iptables. The bridge patch adds a hook so that every packet that the bridge forwards is evaluated by iptables. That patch is available as a kernel module or a small kernel patch that you can apply before compiling. Once the patch is in place, you can write normal iptables rules that reference the bridge interface, just as you would for a standard network interface.

When the bridge is up and running, it can handle everything from simple LAN isolation to complex VPN termination. The key benefit is that you can protect a subnet without re‑routing traffic or touching hosts, which is particularly useful in environments where the upstream router is managed by a third party or locked into a specific configuration. The rest of the article walks through the steps needed to turn a Linux machine into a bridging firewall, from planning the topology to writing iptables rules that keep the network safe.

Why Use a Bridging Firewall

Choosing a bridging firewall usually boils down to a trade‑off: you get powerful filtering without changing the existing network topology. In many corporate environments, the main Internet connection is managed by the ISP or a dedicated router that cannot be reconfigured to set a new gateway. When that happens, you cannot push a firewall into the usual position in front of the router because you have no control over the external routing table. A bridging firewall solves that problem by slipping in between the ISP router and the internal network without requiring any IP or routing changes.

Another common scenario involves a small office that owns a shared ADSL line. The line assigns a /28 network, which gives 16 usable addresses, but the ISP’s router has a fixed IP that the office cannot change. To keep all hosts on the internal network reachable from the Internet, you normally need to configure NAT on a gateway or install a separate firewall that masquerades the public IP. Installing a bridging firewall lets you keep the NAT on the ISP router, so the office can still share the single public IP, but you gain the ability to block unwanted traffic before it reaches the internal network.

Bridging firewalls are also handy when you need to experiment with VPN technologies that require end‑to‑end IP addresses. IP masquerading hides your internal IP range, which can confuse protocols that embed IP addresses in payloads, such as certain SSH or remote‑desktop sessions. With a bridge, the internal hosts keep their original IP addresses, so VPN connections can use the full address space without additional translation layers.

Because the bridge is invisible to the rest of the network, you can deploy it incrementally. Start by routing all internal traffic through the bridge, then add rules that restrict access to certain ports or services. Once the rules are in place, you can turn on the bridge and watch traffic flow through it without having to reboot hosts or modify their routing tables.

Bridging firewalls also simplify management when you have multiple segments that need to share a common security policy. Rather than installing a separate firewall on each subnet, you can place a single bridge between the shared ISP router and a virtual LAN that contains all protected hosts. The single firewall then applies one set of rules across all protected segments, reducing configuration drift and making audits easier.

In short, the bridging firewall approach is attractive when you need to preserve existing routing, avoid NAT complications, or enforce a unified security policy across multiple subnets. The rest of this guide shows how to turn a Linux machine into a fully functional bridging firewall and how to write the iptables rules that keep your network safe.

Planning Your Network Topology

Before you touch any configuration files, sketch the topology you want. In the example that follows, the ISP provides a /28 network – 16 usable addresses. The address range is 10.0.0.48/28, so the usable addresses run from 10.0.0.49 to 10.0.0.62, with 10.0.0.48 reserved for the network, 10.0.0.63 for the broadcast, and 10.0.0.49 as the ISP router’s IP. You’ll split this space into two logical parts: the unprotected side (the ISP router and devices that can see the public Internet directly) and the protected side (all internal hosts that need firewalling). Since a bridge does not create a new subnet, the two sides will share the same IP range but will be separated by the bridge’s filtering logic.

Define two groups of IP addresses: 10.0.0.48–56 for the ISP side and 10.0.0.57–62 for the protected side. This split keeps the ISP router on the unprotected side while all other hosts sit behind the firewall. The firewall itself will get a static IP, 10.0.0.57, on the protected side. That way the firewall appears as just another host on the internal network, but the bridge will filter all traffic that passes through it.

Determine which physical interfaces on the Linux box will connect to each side. Suppose eth0 connects to the ISP router, and eth1 connects to the internal switch that serves the protected hosts. The bridge interface – named br0 – will link eth0 and eth1. After the bridge is up, traffic from the ISP router will flow through eth0, into the bridge, and then to eth1, where it reaches the protected hosts. Traffic from the protected hosts will leave eth1, pass through the bridge, and exit on eth0 to reach the ISP router.

Because the bridge is transparent, you do not need to change the routing table on the protected hosts. They keep their default gateway as the ISP router. However, you can still enforce strict firewall rules on the bridge that limit inbound traffic to specific ports or IP ranges, effectively protecting the hosts without changing their configuration.

With the network layout clarified, you can now focus on the Linux environment. You’ll need a kernel that supports bridging with iptables hooks, the bridge utilities (brctl), and the iptables package. If your distribution’s default kernel does not include the bridge patch, you’ll have to download the patch from http://bridge.sourceforge.net, apply it, and compile a new kernel or load the kernel module. Many modern distributions ship with bridging support out of the box, so check your distribution’s documentation first.

Once the kernel is ready, you can proceed to bring the interfaces down, remove any IP addresses they currently have, and then build the bridge. That preparation step ensures that no traffic leaks through an interface that is not part of the bridge, keeping the system clean and ready for the firewall rules that follow.

Preparing the Linux Environment

Begin by confirming that the kernel can handle a bridge that passes packets through iptables. On most recent distributions you’ll find the bridge code compiled as a loadable module. Load it with:

If the kernel lacks the necessary hook, download the patch from http://bridge.sourceforge.net. The patch is small – just a few dozen lines – but it modifies the core bridge code to call the iptables hook for each forwarded packet. Apply the patch to your kernel source, recompile, and install the new kernel. Alternatively, some vendors provide a pre‑compiled kernel RPM that already contains the patch; Redhat 7.2, for example, ships a ready‑to‑use rpm that you can install with yum.

With the bridge support in place, install the bridge utilities if they are missing:

The bridge utilities provide the brctl command, which is used to create and manage bridge interfaces. You’ll also need the iptables package if it is not already installed:

At this point, make sure that the firewall service is disabled or stopped, because you will be writing your own iptables rules later. On systems that use firewalld, you can stop it with:

Now you can proceed to the next step, which is to clear the network configuration on the interfaces that will become part of the bridge. By removing any existing IP addresses, you prevent the Linux kernel from routing packets directly on those interfaces before the bridge is fully constructed.

Configuring the Bridge

With the kernel and utilities ready, it’s time to assemble the bridge. First, bring the two physical interfaces down and strip them of any IP configuration. This ensures that no traffic leaves the machine until the bridge is fully built:

Next, create the bridge interface and add the two physical interfaces to it. The bridge interface will be named br0, but you can choose any name that makes sense for your environment:

At this point the bridge exists, but it does not yet have an IP address. Assign the firewall’s IP to the bridge so that it can manage the internal network and respond to management traffic:

Now the Linux box is acting as a bridge. Packets that enter eth0 will be forwarded to eth1 and vice versa, but only after passing through the bridge code. The next step is to enable iptables filtering on the bridge. The bridge patch hooks the iptables chain called FORWARD, so all traffic that passes through the bridge will be subject to the rules you write in the FORWARD chain. You can also apply rules to INPUT and OUTPUT if you wish to restrict traffic that originates from or targets the firewall itself.

Verify the bridge is up by running:

The output should list br0, its attached interfaces, and a status of up. You can also check the kernel log for any bridge messages: