I basically just followed the OpenBSD documentation! One of the big advantages of OpenBSD is that pretty much everything you need to know is contained in the manpages.
As I'd said above, we ended up using RFC 3378 EtherIP to link the two layer 2 broadcast domains across the Wireguard tunnel. OpenBSD supports this with the etherip interface. You end up creating a bridge with the etherip interface and whatever physical Ethernet interfaces you want to bridge, on either side of the Wireguard tunnel.
I also tried VXLAN but did not have good results. I'm not entirely sure it wasn't a problem with my configuration. Traffic often went one-directional, where broadcast packets from Site A made it to Site B, but they did not come from Site B to Site A. EtherIP worked right off, so I didn't investigate further.
The docs are indeed great, but to me it seems like they are recommending GENEVE (RFC 8926):
> Generic Network Virtualization Encapsulation (GENEVE) supports all of the capabilities of VXLAN, NVGRE, and STT and was designed to overcome their perceived limitations. Many believe GENEVE could eventually replace these earlier formats entirely
I'm bit surprised that they didn't have section on vxlan there considering it is pretty popular afaik?
Anyways, I think tunneling GENEVE (or any other Ethernet-over-IP protocol) should work fine over WireGuard, same as using regular network interfaces.
Since WireGuard is Layer 3, what would is everyone's use case of doing Layer 2 on it? Or, what can it improve over existing solutions? I have tried to do the same for a bit while still learning networking, but ran into Layer 3 limitations.
Frustratingly enough, apparently not as I could never get it to work. It is pretty easy to set up a vxlan tunnel over wireguard if you absolutely need stuff like that though.
Oh hadn't thought about that, thanks. 'need' is a big word here but sometimes you can't change the client and server apps so, having support for the basic (although niche) features in the lower layers helps migrating smoothly.
Bonjour is built on top of DNS. You don't need a layer 2 tunnel to make it work.
However, it normally does rely on multicast. Rather than trying to bridge broadcast domains (which is going to cause performance issues), a more efficient option is to setup an Avahi mDNS reflector on either end of the tunnel to rebroadcast mDNS packets.
Alternatively, there's also a Wide-Area Bonjour service that works over unicast and doesn't need any special packet forwarding, provided you run a Bonjour-aware DNS server:
You are technically correct (best kind of correct) however, in reality, I see folks using L2 tunnels to solve for bonjour etc all the time. Usually those without networking knowledge to solve the forwarding.
Yeah, you can do it the right way...or you can just tunnel layer 2 and forget about it. I see it done a fair bit for both Bonjour/Avahi and DHCP (why?).
The best way to perform something like this on Layer 2 is to use Shortest Path Bridging (SPB) based on IEEE 802.1Q-2018. However the Linux kernel does not yet fully supporting this feature natively although the standard has been out for quite sometime and already being supported by commercial network solutions and the popular Open vSwitch (OVS) [1].
[1] Ask HN: Project ideas for a Linux kernel module:
As I'd said above, we ended up using RFC 3378 EtherIP to link the two layer 2 broadcast domains across the Wireguard tunnel. OpenBSD supports this with the etherip interface. You end up creating a bridge with the etherip interface and whatever physical Ethernet interfaces you want to bridge, on either side of the Wireguard tunnel.
I also tried VXLAN but did not have good results. I'm not entirely sure it wasn't a problem with my configuration. Traffic often went one-directional, where broadcast packets from Site A made it to Site B, but they did not come from Site B to Site A. EtherIP worked right off, so I didn't investigate further.