-----------------------
notes.superlogical.ch
-----------------------
Home. Pages. Posts. Sticky notes.
There is no Layer2 option in WireGuard
Last update: 07.06.2020 21:20
As stated in the first sentence of “WireGuard: NextGeneration Kernel Network Tunnel” [1]
WireGuard is a secure network tunnel, operating at layer 3, implemented...
All questions on StackExchange regarding WireGuard and bridging, broadcast traffic are answered pretty quickly: “It’s layer 3”. Period… Except maybe in the future multicast and IPv6 link local addresses, eventually.
Over the past years, I migrated lots of VPNs to WireGuard. Since it has found its way into the Linux Kernel (Premier Commit) it has become my first option to choose, when it comes to VPN.
Now in 99.5% of the cases, implementing VPN at layer 3 is the required solution. In .5% there is no way around at least a bit layer 2. Thinking of OpenVPN TAP interfaces I was looking for a way to close the gap. A good friend of mine, \@kpanic, a pretty busy guy in the Freifunk FF3L Community gave me a good hint: “Ever thought about GRETAP?”.
GRE stands for Generic Routing Encapsulation and is defined in RFC 2784. GRE interfaces operate on layer 3. In Linux there is a thing called “gretap”. It’s a GRE tunnel based TAP interface. And because it is a TAP, it simulates a link layer device and therefore carrying Ethernet frames. I’ve not found good documentation about, but in the kernel source.
GRE | Ethernet | IPv4 Header | GRE Header | Inner IP Header | Payload | |
GRETAP | Ethernet | IPv4 Header | GRE Header | Inner Ethernet Header | Inner IP Header | Payload |
Compared to GRE, in GRETAP there is a “Inner Ethernet Header”. Keep in mind, this all adds up on our network overhead.
The case
Two sites, both with a private //24 IPv4 network, both Debian 10 boxes, installed on a APU2 based router with three gigabit ethernet NICs installed.
The plan is, that the third NIC (enp3s0) on router A gets bridged transparently to enp2s0 on router B. Giving anything plugged to enp3s0 on router A the full Layer 2 experience as directly connected to the Switch on Site B
On both sites: A WAN/Cable modem on enp1s0, network devices firewalled, behind a switch on enp2s0. Let’s call them Router A & B / Site A & B.
- Site Network A: 192.168.178.0/24
- Site Network B: 192.168.92.0/24
WireGuard Config on Router A
|
|
WireguardConfig on Router B
|
|
How I think it could be solved
There are some prerequisites to be in place to make the bridge setup work
Ensured, IPv6 forwarding is enabled on both sites (This should be given on a router)
|
|
bridge-utils installed on both sites
|
|
MSS clamping on both sides in FORWARD (This is the quick** method of getting MSS right)
|
|
and br_netfilter gets loaded on boot. If not, your iptables forward rules will not work for the resulting bridge.
|
|
Time to create a bridge interface on both sides.
Router A: In /etc/network/interfaces we create a bridge and connect enp3s0 to it. There is no IP configuration on enp3s0 nor on the bridge.
|
|
Router B: In /etc/network/interfaces we create a bridge and connect enp2s0 to it on boot. The bridge is configured to static internal network 192.168.92.1⁄24 IP on enp2s0 the address set to manual with no address
|
|
Append PostUp & Down scripts on wg0.conf at Router A
|
|
Append PostUp & Down scripts on wg0.conf at Router B
|
|
Sources
- Title image: https://www.wireguard.com/img/wireguard.svg
- [1]Paper “WireGuard: NextGeneration Kernel Network Tunnel” Jason A. Donenfeld, https://www.wireguard.com/papers/wireguard.pdf
© 2020 notes.superlogical.ch. GitLab. Github. Twitter. Impressum & Datenschutzerklärung.