Best way to have a network bridge with both my LAN and WAN (not AP) interfaces attached?

I have this configuration to put my LAN and WAN (not AP) network interfaces on the same bridge but I'm wondering if there is a better way to do it? Has anyone done this in a better way? Thanks.

I've only tested it on Ubuntu 22.10 with Network Manager disabled and systemd-networkd enabled. I did that part like this:

sudo systemctl disable --now NetworkManager-dispatcher.service NetworkManager-wait-online.service NetworkManager.service
sudo systemctl enable --now systemd-networkd.service

Install some packages, you definitely need iw while bridge-utils and ebtables are optional but good to have for troubleshooting, etc.

sudo apt install bridge-utils ebtables iw

In the netplan yaml file below:

• Replace eth0 with the name of your LAN network interface.
• Replace wlan0 with the name of your LAN network interface. For network interface names, see the output of running these commands: ip a and ip l

Create: /etc/netplan/02-bridge.yaml

Contents:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
  wifis:
    wlan0:
      dhcp4: no
      access-points:
        "<your SSID>":
          password: "<your password>"
  bridges:
    br0:
      dhcp4: yes
      interfaces:
        - eth0
        - wlan0

Copy the systemd-networkd.service unit file to the directory where administrators can override unit files. It is not safe to edit a unit file under /lib/systemd/system because a package update can overwrite your modifications. This is by design.

sudo cp /lib/systemd/system/systemd-networkd.service /etc/systemd/system/systemd-networkd.service

Then edit /etc/systemd/system/systemd-networkd.service, adding an ExecStartPre above the existing ExecStart.

$ diff -u /lib/systemd/system/systemd-networkd.service /etc/systemd/system/systemd-networkd.service
--- /lib/systemd/system/systemd-networkd.service    2022-09-20 11:19:06.000000000 -0400
+++ /etc/systemd/system/systemd-networkd.service    2022-10-09 20:48:35.657885031 -0400
@@ -23,6 +23,7 @@
 BusName=org.freedesktop.network1
 CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
 DeviceAllow=char-* rw
+ExecStartPre=-/sbin/iw dev wlan0 set 4addr on
 ExecStart=!!/lib/systemd/systemd-networkd
 ExecReload=networkctl reload
 LockPersonality=yes

I do that because the iw ... 4addr, which turns on WDS mode has to happen before the wlan0 interfaces is added to the br0 bridge or you get:

Oct 09 14:14:34 wookums systemd-networkd[2006]: wlan0: Failed to set master interface: Device does not allow enslaving to a bridge. Operation not supported

Once WDS ("4addr") mode is enabled that error no longer happens.

I tried to use networkd-dispatcher to set WDS ("4addr") mode but it is started after systemd-networkd attempts to put wlan0 into the br0 bridge and fails because WDS has not yet been enabled.

It seems really gross to have to cram something into systemd-networkd.service just to have one line of code be run before something goes wrong because it wasn't run in time.

Aside from the obvious improvement of using a systemd unit file drop-in instead of copying all of systemd-networkd.service into /etc/systemd/system, is there any way to this better?

UPDATE:

• wpa_supplicant connects to the AP using DHCP; the AP is a DHCP server and the wlan0 is a client. However, the IP address of wlan0 (acquired via DHCP) does not appear to be visible because bridge slaves do not have IP addresses assigned, only the bridge itself has one. The br0 and wlan0 interfaces will not have the same IP address; the wlan0 interface will not be usable even though brctl show and ip a, etc. will look OK.

Thanks KES

Linux offers several ways of configuring network interfaces. Each one has its own advantages and drawbacks. Each is geared towards a set of usecases and tends to become unwieldy when applied to a usecase outside what its creators had in mind.

The old sys5init up/down scripts were the most flexible solution since you could write into the scripts exactly what you needed. They were however error-prone and complicated for non-experts to handle and therefore fell out of favor. At the other end of the spectrum is NetworkManager which tries to automate everything so that the user doesn't have to think about it, thereby making it very hard for those who know exactly which settings they want to actually get them. Netplan is in the middle ground, accomodating a pretty wide range of setups easily, but there are scenarios like yours (setting RDS/4-address-mode on a wireless interface) which are not in its repertoire so you have to resort to scripting.

That said, there is an alternative to creating a custom systemd-networkd.service script. That is, create a udev rule as described in https://superuser.com/questions/1601099/how-to-automatically-enable-wifi-4addr-wds-mode-before-connecting-to-specific over on SuperUser. The limitation mentioned there (not being able to connect to non-RDS WLANs anymore) will probably not hurt you.

A note on DHCP:

Bridging is a layer 2 mechanism. The two bridged networks (LAN and WLAN) become a single broadcast domain, so a single DHCP server will cover them both. You should disable the DHCP server in your AP since your LAN DHCP server will also provide IP addresses to the WLAN once the bridge is up.

By the same reason, the member interfaces of the bridge cannot have and do not need individual layer 3 configurations such as IP addresses. Only the bridge as a whole has a layer 3 configuration. You enable the member interfaces eth0 and wlan0 and connect wlan0 to the AP via wpa_supplicant on layer 2 only, without assigning an IP address, by virtue of the dhcp*: no lines in your netplan configuration. Then you join them to the bridge. Only once that's done you run DHCP through the bridge interface to get one IP address from the (one) DHCP server serving your combined LAN/WLAN network segment.

(You could in theory run DHCP with only one interface in the bridge and the other one would then share the acquired IP address upon joining, but I recommend against it.)