Linux Network Bridging in Practice: Designs, Configuration and Security

Overview

A Linux server can act as a switch, a router or both. People often reach for a bridge when what they need is a router, and the difference decides how safe the network is. A bridge joins networks into one. A router keeps them separate and forwards traffic between them.

This article explains how a Linux bridge works, then covers six designs for connecting an internal server network to an external network through one Linux gateway. Each design has a diagram, commands for Ubuntu and CentOS-family systems, and its security risks and limits.

If you read only one part, read Scenario B and the security section. Together they cover the most common design: one gateway with several servers behind it.

How a Linux bridge works

A Linux bridge is a virtual switch inside the kernel. It forwards Ethernet frames between the interfaces attached to it, based on destination MAC addresses (Red Hat Developer). It works at Layer 2 and never looks at IP addresses.

The bridge forwards a frame to the port where it last saw the destination MAC address. The host talks to the bridge network through br0.

Bridge, router and NAT compared

Two facts explain most bridging problems:

1. A port no longer handles IP traffic directly. Move the IP address from the NIC to the bridge.
2. A bridge never changes IP addresses. It cannot make a private subnet reachable from another network. Only routing and NAT can.

The example network: four servers, one uplink

All scenarios use one small example network. Only one of its four servers, called the gateway here, has a NIC on the external network. The other three sit on an internal network behind it and reach the outside only through the gateway. The same ideas apply to any number of servers.

Server 1 is the only machine with a foot in both networks. Every scenario below is a choice about what it does with traffic between its two NICs.

Questions to settle before choosing a design:

1. Must the internal servers be reachable from outside, or only able to reach out (updates, time, DNS)?
2. Can the external network give you more than one address, or a routed subnet?
3. Who runs the external network? Port security, 802.1X or segmentation policy there can rule out bridging.
4. How many internal ports does the gateway have: one NIC to a switch, or several NICs straight to servers?
5. Does the gateway also run virtual machines or containers?
6. Is it acceptable, under your security policy, for these servers to reach the internet at all?

All examples use documentation address ranges and these names. Real interface names are often enp3s0 rather than eth0; check yours with ip -br link.

Scenario A: bridge the uplink and the internal network (Layer 2)

Bridging eth0 and eth1 merges the external and internal networks into one. Every server then lives on the external subnet, as if it were plugged into the upstream switch.

The bridge passes frames through. It makes no routing decision, so the upstream router sees each server directly.

Four things must be true for this to work:

• Servers 2 to 4 need addresses in the external subnet (192.0.2.0/24), static or from the upstream DHCP server. Their old 10.10.10.x addresses are useless, because the upstream router knows nothing about that subnet.
• The upstream port must accept several MAC addresses. Port security or 802.1X on that port will block the extra servers.
• The uplink must be wired Ethernet. A Wi-Fi interface in client mode cannot normally be bridged. The kernel only allows it when both sides negotiate four-address mode (kernel commit).
• The gateway’s own IP address moves from eth0 to br0.

On the gateway, as a temporary setup that is lost on reboot:

ip link add br0 type bridge
ip link set br0 up
ip addr flush dev eth0
ip link set eth0 master br0
ip link set eth1 master br0
ip link set eth0 up
ip link set eth1 up
ip addr add 192.0.2.10/24 dev br0
ip route add default via 192.0.2.1

ip addr add 192.0.2.12/24 dev eth0
ip route add default via 192.0.2.1

No ip_forward and no NAT are needed, because the gateway never routes. It only switches frames.

Use it when the external network is trusted and managed by you, and the gateway is just acting as a small switch. Avoid it when the external side is the internet or any less trusted network.

Scenario B: two networks, routing and NAT (recommended)

The gateway keeps the internal network separate and forwards traffic between the two sides. NAT, here masquerade, rewrites the internal source addresses to the gateway’s external address, so the external network sees one host.

The gateway is a router here, not a switch. The two sides stay separate, and the firewall decides what crosses.

Do you need a bridge here? Not if the gateway has a single internal NIC. Put the address on eth1 and skip step 1, then use eth1 wherever the firewall rules below say br0. Use a bridge when the gateway has several internal ports you want to act as one switch, or when VMs and containers join the internal network. The steps below use br0 for the internal side.

Step 1: build the internal bridge

ip link add br0 type bridge
ip link set br0 up
ip link set eth1 master br0
ip link set eth1 up
ip addr add 10.10.10.1/24 dev br0

Step 2: turn on forwarding

The uplink NIC keeps its own address and default route. Then enable IPv4 forwarding, now and after reboot (OneUptime):

sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-ip-forward.conf
sysctl --system

Step 3: firewall and NAT with nftables

The masquerade rule is the standard form from the nftables wiki. Masquerade suits an uplink whose address may change. With a fixed address, snat to <address> does the same job. The rules around it default to drop, so only listed traffic passes.

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iifname "lo" accept
    ct state established,related accept
    ip protocol icmp accept
    ip6 nexthdr ipv6-icmp accept
    iifname "br0" tcp dport 22 accept
    # add DNS here only if the gateway runs a DNS forwarder:
    # iifname "br0" udp dport 53 accept
    # iifname "br0" tcp dport 53 accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "br0" oifname "eth0" accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oifname "eth0" masquerade
  }
}

nft -c -f /etc/nftables.conf   # check only, applies nothing
nft -f /etc/nftables.conf      # load

The distribution’s nftables service loads its own rules file at boot, and the file’s location differs between distributions. If the uplink uses DHCP, also allow UDP port 68 on eth0. These rules cover IPv4 NAT. IPv6 is a separate path: the inet table filters both, but only IPv4 is translated.

On CentOS, RHEL, AlmaLinux and Rocky Linux, firewalld manages the firewall. The CentOS section further down shows the same NAT setup with firewalld.

Step 4: point the other servers at the gateway

On each of Servers 2, 3 and 4 (use .3 and .4 for the others):

ip addr add 10.10.10.2/24 dev eth0
ip route add default via 10.10.10.1

They also need a DNS resolver they can reach. Either use the upstream resolver, which the forward rule above already allows through, or run a forwarder such as dnsmasq on the gateway.

Step 5: test

1. From Server 2, ping 10.10.10.1, then 192.0.2.1, then a public address.
2. Resolve a hostname, to prove DNS works.
3. On the gateway, run tcpdump -ni eth0 while pinging from Server 2. The source must show 192.0.2.10, not 10.10.10.2.

Inbound access is closed by default, because new connections from outside are dropped. You can open a single service with destination NAT, but every such rule exposes a server. Put a reverse proxy in front instead where you can.

Scenario C: route without NAT

If the upstream network can route a subnet to you, you can skip NAT. The gateway still routes between two separate networks, but the internal servers keep their own addresses and the outside world sees them as they are.

The setup is Scenario B without the masquerade rule. Keep forwarding enabled and keep the default-drop forward chain. Two things change:

• The upstream router needs a route to the internal subnet, pointing at the gateway’s external address. In plain words: “to reach 10.10.10.0/24, send traffic to 192.0.2.10”. The syntax depends on the router.
• The internal addresses must be valid on the upstream side. Private ranges like 10.10.10.0/24 only work inside a network that carries your route. To reach the public internet this way, you need a public subnet routed to you by your provider.

The most common failure is outbound packets that leave but never get replies. The upstream router has no return route, so it discards the answers. Either add the route or go back to NAT.

Scenario D: virtual machines and containers on the gateway

Hypervisors and container runtimes attach each guest to a bridge through a tap or veth device. The bridge on the gateway can then be set up in two ways, and they map onto Scenarios A and B.

Isolated bridge with NAT. This is Scenario B in miniature. libvirt’s default network works this way: the host gets an isolated bridge, virbr0, with no physical interfaces attached. Guests reach the outside through NAT and forwarding, and libvirt adds the iptables rules for it (libvirt wiki). Guests are hidden from the external network.

Bridged guests. This is Scenario A. The uplink NIC joins the bridge, and each guest appears on the external network with its own MAC and IP address. The upstream port must accept all those MAC addresses. It cannot work over Wi-Fi, because wireless interfaces cannot be attached to a Linux host bridge (libvirt wiki).

When the gateway also runs Docker

Docker interacts with the firewall in ways that surprise gateway builders (Docker docs):

• Its default bridge network needs IP forwarding. If Docker enables forwarding itself, it also sets the FORWARD chain policy in the iptables filter table to DROP.
• Rules you append to FORWARD run after Docker’s rules. Put your own rules in the DOCKER-USER chain, which Docker processes first.
• By default, any external source address can connect to a published port.

After installing Docker on a gateway, retest forwarding and review the rules.

The left pattern hides guests behind the gateway. The right pattern puts each guest on the external network.

Scenario E: one bridge, several VLANs

Use a VLAN-aware bridge when the gateway’s internal ports carry servers of different trust levels, for example application servers and a management network, and you want them kept apart on the same hardware. VLAN filtering has been available since kernel 3.8 (Red Hat Developer).

The bridge keeps the two VLANs apart at Layer 2. Routing between them happens only at the gateway, where the firewall rules apply.

This example puts eth1 in VLAN 10 and eth2 in VLAN 20 as access ports, so the servers on them send and receive untagged frames:

ip link set br0 type bridge vlan_filtering 1
ip link set eth1 master br0
ip link set eth2 master br0
bridge vlan add dev eth1 vid 10 pvid untagged
bridge vlan add dev eth2 vid 20 pvid untagged
bridge vlan del dev eth1 vid 1
bridge vlan del dev eth2 vid 1
bridge vlan show

New ports start in the default VLAN 1. The two del lines take the access ports out of it. A trunk port to another switch carries several tagged VLANs. For example, bridge vlan add dev eth3 vid 10-20 allows VLANs 10 to 20 on eth3.

VLANs only separate traffic at Layer 2. For the gateway to route between them, or out to the internet, give each VLAN its own interface on the bridge:

bridge vlan add dev br0 vid 10 self
ip link add link br0 name br0.10 type vlan id 10
ip addr add 10.10.10.1/24 dev br0.10
ip link set br0.10 up

Repeat for VLAN 20 with its own subnet. Then the same Scenario B rules apply, with br0.10 and br0.20 in place of br0. Because the forward chain defaults to drop, the VLANs cannot reach each other unless you allow it.

A related tool is filtering inside the bridge itself. nftables has a bridge family for rules on Layer 2 frames, and it works without the br_netfilter module (kernel docs). It is the right place for rules that must apply to bridged traffic, as in Scenario A.

Scenario F: the gateway between an external switch and an internal switch

In many server rooms the gateway is cabled to two physical switches. One carries the external network and the other carries the internal network. The gateway has at least two NICs: eth0 to the external switch and eth1 to the internal switch. What the gateway does between them decides the design.

The gateway’s two NICs sit on separate switches. The dashed path shows the one mistake that matters most in the bridged design.

Routed gateway (recommended). eth0 and eth1 stay separate interfaces with their own addresses. The gateway forwards between them and applies the firewall and, if wanted, NAT. This is Scenario B or C with a real switch on each side. The two switches never share a broadcast domain, so a loop or a broadcast storm on one side cannot spread to the other.

Bridged gateway. br0 holds eth0 and eth1. The gateway becomes a two-port switch between the two switches, which then form one Layer 2 network. This is Scenario A with physical switches on both sides. It suits two jobs: extending one network across two switches, and acting as an inline Layer 2 filter. For the second job, nftables has a bridge family for rules on frames that cross the bridge.

ip link add br0 type bridge
ip link set br0 type bridge stp_state 1 priority 61440
ip link set eth0 master br0
ip link set eth1 master br0
ip link set br0 up
ip link set eth0 up
ip link set eth1 up

A bridge forwards frames without an IP address of its own. Without one, the gateway is not reachable on that network (OneUptime). Give management access to a separate interface, not to the bridged network.

Rules for the bridged design:

• One path only. If the two switches are also linked another way, such as a spare cable, a second gateway, or a VM host that bridges both networks, frames loop. Without STP the result is a broadcast storm. With STP, one of the paths is blocked (kernel docs).
• Control the STP root. With STP on, the bridge exchanges STP messages with both switches and could become the root bridge. Lower priority values win (NetworkManager reference), so give the gateway a high number, as in the example, and leave the root role to a switch.
• Switch port security. Each switch now sees the MAC addresses of the devices on the other side through one port. Port security or 802.1X on those ports can block that.
• VLANs. If the switches use trunks, the bridge must carry the same VLANs. Use a VLAN-aware bridge with trunk ports, as in Scenario E.
• Fail-closed. If the gateway stops, the link between the two networks stops with it. Plan for that.

Choosing a scenario

Start with Scenario B. Move to another one only when a specific requirement rules it out. The flow below shows the usual decision path, and the table compares the outcomes.

Read the flow from the top left. Most four-server setups end at Scenario B.

Making it permanent and checking it

The ip commands in the scenarios last until reboot. For a permanent setup, use whichever network tool your distribution already manages the interfaces with, and use only one of them per interface.

Ubuntu uses netplan by default, and CentOS-family systems use NetworkManager. Both are shown below, along with systemd-networkd.

Before you touch a live NIC

1. Make sure you have console or out-of-band access. Moving an address onto a bridge can drop your own SSH session.
2. Record the current state: ip -br addr, ip route, ip -br link.
3. Add the bridge and move the address in one step, not over several logins.
4. Prefer a method that can roll back. On Ubuntu, netplan try reverts the change if you do not confirm it.

Netplan (Ubuntu)

Scenario B. The uplink keeps its address, and the internal bridge holds eth1. Member interfaces must also be defined under ethernets, and STP settings go under parameters (OneUptime):

network:
  version: 2
  ethernets:
    eth0:
      addresses: [192.0.2.10/24]
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.1]
    eth1: {}
  bridges:
    br0:
      interfaces: [eth1]
      addresses: [10.10.10.1/24]
      parameters:
        stp: false

For Scenario A, put both NICs in the bridge and move the uplink addressing onto it:

network:
  version: 2
  ethernets:
    eth0: {}
    eth1: {}
  bridges:
    br0:
      interfaces: [eth0, eth1]
      addresses: [192.0.2.10/24]
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.1]

Apply with netplan try, confirm, then check with bridge link show. Keep the file readable by root only: chmod 600.

Set STP on purpose, whichever tool you use. NetworkManager turns it on by default, and in Scenario A the bridge faces the upstream network, which will then see the bridge’s STP messages.

systemd-networkd

# 10-br0.netdev
[NetDev]
Name=br0
Kind=bridge

# 20-br0.network
[Match]
Name=br0
[Network]
Address=10.10.10.1/24

# 30-eth1.network
[Match]
Name=eth1
[Network]
Bridge=br0

The uplink needs its own .network file. Enable forwarding with the sysctl.d file from Scenario B.

CentOS, RHEL and other Red Hat family systems (NetworkManager and firewalld)

NetworkManager manages bridges as connection profiles. The bridge settings and their defaults (NetworkManager reference) are:

CentOS Stream and its relatives (RHEL, AlmaLinux, Rocky Linux) use NetworkManager and firewalld by default, and the network-scripts package is not installed by default on version 9 (RackNerd). Use nmcli. These commands build the internal bridge of Scenario B: eth1 joins br0, which holds the internal address (OneUptime).

nmcli connection add type bridge con-name br0 ifname br0
nmcli connection modify br0 bridge.stp no
nmcli connection modify br0 ipv4.addresses 10.10.10.1/24
nmcli connection modify br0 ipv4.method manual
nmcli connection add type ethernet port-type bridge con-name br0-port1 ifname eth1 controller br0
nmcli connection up br0
nmcli connection up br0-port1
bridge link show

Current releases name the port options port-type and controller. Older releases used slave-type and master. If nmcli rejects a command, check man nmcli on your system. For Scenario A, add the uplink NIC to the bridge the same way and move the uplink address onto br0. The Red Hat networking guide has the full chapter for each release.

For NAT, use firewalld instead of the nftables file from Scenario B, and do not run both. Put the uplink in the external zone, put the bridge in the internal zone, enable masquerade on the external zone, and add a policy that lets internal traffic out (OneUptime):

firewall-cmd --permanent --zone=external --change-interface=eth0
firewall-cmd --permanent --zone=internal --change-interface=br0
firewall-cmd --permanent --zone=external --add-masquerade
firewall-cmd --permanent --new-policy internal-to-external
firewall-cmd --permanent --policy internal-to-external --add-ingress-zone internal
firewall-cmd --permanent --policy internal-to-external --add-egress-zone external
firewall-cmd --permanent --policy internal-to-external --set-target ACCEPT
firewall-cmd --reload

This policy accepts all internal traffic towards the external side. Narrow it to the services the servers need, as the best-practices checklist advises. Forwarding still needs the sysctl.d setting from Scenario B.

Verify

Security concerns

A gateway sits between networks of different trust, so it concentrates risk. The table lists the main concerns and what reduces each one.

A good test is to assume one internal server is compromised and ask what it can reach. If the answer is “anything on the internet and every other server”, tighten the rules.

Best practices

Design

• Prefer routing over bridging between networks of different trust.
• Bridge only what must share a Layer 2 segment.
• Use an internal bridge only when you need it: several internal ports, or VMs and containers.
• Write down the topology, address plan and who owns the external side.

Bridge configuration

• Put the IP address on the bridge, never on its ports.
• Set STP explicitly. Some tools turn it on by default, for example NetworkManager.
• Use the same MTU on all ports of a bridge.
• Give the bridge a fixed MAC address if the upstream relies on DHCP reservations or port security, because br0 is a separate interface with its own MAC.
• Manage each interface with one tool only: netplan, NetworkManager, systemd-networkd or manual ip, not a mix.
• Use bridge and ip commands. The older brctl tool is legacy.
• Keep a console or out-of-band path, and use a rollback method such as netplan try.

Firewall and NAT

• Default-drop input and forward, then allow only what is needed.
• Limit outbound traffic from internal servers to the destinations they need.
• Cover IPv4 and IPv6 in the same ruleset, or disable IPv6 deliberately.
• Allow SSH to the gateway from the internal side only.
• Log denied and forwarded traffic, and send logs to another host.
• Make forwarding and rules persistent, then reboot once and test.

Hardening and operations

• Use isolated ports, VLANs or both where servers must not reach each other.
• Set guard on on ports where no STP BPDUs should ever arrive.
• Keep the gateway minimal and patched. Do not run extra services on it.
• Back up the network and firewall configuration.
• Plan for gateway failure. One gateway is a single point of failure. For two gateways, VRRP with a tool such as keepalived is a common approach.
• Test from outside and from a compromised-server point of view, not only from the happy path.

Troubleshooting

Limitations and gotchas

• Wi-Fi. A managed-mode Wi-Fi interface cannot normally be a bridge port. Only four-address mode, set up on both sides, allows it (kernel commit, libvirt wiki).
• Layer 2 only. A bridge does not route, does not translate addresses and cannot make a private subnet reachable from outside.
• STP is classic. Linux bridges do not support RSTP (Red Hat Developer), so failover after a link change is slower than with RSTP.
• Software forwarding. Bridging and NAT run on the gateway’s CPU, so its throughput depends on the hardware.
• NAT limits. The connection-tracking table has finite capacity. Inbound access needs extra rules. Masquerade needs kernel 3.18 or later (nftables wiki).
• Single point of failure. If the gateway is down, the other servers lose their way out. One uplink also means shared bandwidth.
• Tool conflicts. Two tools managing the same interface will overwrite each other’s settings.
• br_netfilter is legacy. The kernel docs discourage it and suggest nftables (kernel docs).
• VLAN defaults. VLAN filtering is off by default, and new ports start in VLAN 1 once it is on.
• Upstream consent. Bridging changes what the external network sees. Port security, 802.1X or policy there can block it.

References

• Linux kernel documentation: Ethernet bridging
• bridge(8) manual page, iproute2
• Introduction to Linux bridging commands and features (Red Hat Developer)
• NetworkManager reference: bridge settings
• Red Hat Enterprise Linux 8: Configuring a network bridge
• nftables wiki: Performing Network Address Translation (NAT)
• Docker documentation: Docker with iptables
• libvirt wiki: Networking
• Linux kernel commit: cfg80211, disallow bridging managed and ad-hoc interfaces
• OneUptime: How to configure a bridge with Netplan
• OneUptime: How to create a network bridge on Linux using iproute2
• OneUptime: How to configure IP forwarding and enable routing on Ubuntu
• OneUptime: How to configure a network bridge with nmcli on RHEL
• OneUptime: How to configure RHEL as a router with IP forwarding and NAT
• RackNerd: Installing network-scripts on AlmaLinux 9, Rocky Linux 9 and CentOS Stream 9

The systemd-networkd files, netplan try, the VLAN self and default-VLAN details, the nftables inet ruleset, the older NetworkManager option names (slave-type, master) and the STP priority value in Scenario F follow standard documented usage but were not checked line by line against the pages above. Test them on a lab machine first.