How can I make the Wake-on-LAN (WoL) magic packet travel from the VXLAN over WireGuard to the local network on the other end of the VXLAN?

Installing and Using OpenWrt Network and Wireless Configuration
1

The output of the ip a command on the client-side.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:16:96:ff:ff:ff brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:96:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.90/24 brd 10.10.10.255 scope global br0
       valid_lft forever preferred_lft forever
    inet 192.168.15.103/24 metric 1024 brd 192.168.15.255 scope global dynamic br0
       valid_lft 7163sec preferred_lft 7163sec
    inet6 2001:0db8:85a3:0000:0000:8a2e:0370:7334/64 scope global temporary dynamic 
       valid_lft 86361sec preferred_lft 14361sec
    inet6 fe80::216:96ff:feec:3c06/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
4: vxlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 96:9f:df:ff:ff:ff brd ff:ff:ff:ff:ff:ff
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.6/24 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fdc9:281f:4d7:9ee9::6/64 scope global 
       valid_lft forever preferred_lft forever

Network configuration for the opposite end.

cat /etc/config/network 
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        list ports 'eth2'
        list ports 'vxlan0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '10.10.10.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'ffffff'
        option listen_port '11111'
        list addresses '10.0.0.1/24'
        list addresses 'fdc9:281f:04d7:9ee9::1/64'
        option defaultroute '0'

config wireguard_wg0
        option description 'text'
        option public_key 'ffffff'
        list allowed_ips 'fdc9:281f:04d7:9ee9::6/128'
        list allowed_ips '10.0.0.6/32'

config interface 'vxlan0'
        option proto 'vxlan'
        option tunlink 'wg0'
        option vid '1'
        option port '4789'

cat /etc/config/firewall
config zone 'lan'
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'
        list network 'lan'
        list network 'wg0'
        list network 'vxlan0'

wol -i 10.10.10.255 00:d8:61:ff:ff:ff

It is specified that sending a magic packet from 10.10.10.255 can wake up a computer in the local area network, but without specifying it, it cannot wake up.

After connecting the vxlan0 bridge to br0, WoL started working.
The network configuration of the client.

cat /etc/systemd/network/20-br0.netdev
[NetDev]
Name=br0
Kind=bridge
MACAddress=none

cat /etc/systemd/network/21-br0_bind.network
[Match]
Name=enp*s0

[Network]
Bridge=br0

cat /etc/systemd/network/22-br0.network
[Match]
Name=br0

[Network]
Address=10.10.10.90/24
DHCP=yes
MulticastDNS=true
IPv6Token=prefixstable
IPv6PrivacyExtensions=prefer-public
[Link]
RequiredFamilyForOnline=ipv4

cat /etc/systemd/network/30-vxlan0.netdev
[NetDev]
Name=vxlan0
Kind=vxlan

[VXLAN]
VNI=1
DestinationPort=4789
Remote=10.0.0.1
Independent=true

cat /etc/systemd/network/31-vxlan0_bind.network
[Match]
Name=vxlan0

[Network]
Bridge=br0

cat /etc/systemd/network/40-wg0.netdev
[NetDev]
Name=wg0
Kind=wireguard
Description=WireGuard tunnel wg0

[WireGuard]
ListenPort=11111
PrivateKey=ffffff

[WireGuardPeer]
PublicKey=ffffff
AllowedIPs=10.0.0.1/32
AllowedIPs=fdc9:281f:04d7:9ee9::1/128
Endpoint=xy.test.com:11111
PersistentKeepalive = 25

cat /etc/systemd/network/41-wg0.network
[Match]
Name=wg0

[Network]
Address=10.0.0.6/24
Address=fdc9:281f:04d7:9ee9::6/64
2

Probably not related to your problem, but it looks like a site-to-site setup between two routers/VPS?

If so disable masquerading and add the subnet of the other side as allowed IPs.
Do that on both sides.

EDIT:
are you sure you have wol installed (which wol)?
I use etherwake or actually I use LuCi (which uses etherwake) to revive my PC

1 Like
3

If you want to have a layer2 lan to lan connection through vxlan within the Wireguard tunnel then you have to bridge lan and vxlan interface but not the Wireguard interface to the LAN bridge.

4

What's the Wireguard configuration for the non-OpenWrt peer? Can you draw a network map of the nodes involved here? In particular, what's the intended IP addressing plan?

An alternative solution for your consideration: remotely command the OpenWrt router to generate the magic packet locally on your behalf. Using SSH and the etherwake package, you could do something like this:

ssh root@<router IP addr> etherwake -i br-lan <target MAC addr>

This way you won't need a layer 2 tunnel (VXLAN) nested inside a layer 3 tunnel (Wireguard).

1 Like
5

You may be right, GPT mentioned that the wol seems to send magic packets to the physical network card, or bridge, which means it seems like I should bridge vxlan to br0 on the client side as well.

Does this mean that I should be doing dhcp snooping on vxlan0 on the client side? Otherwise, the DHCP may become abnormal.

6

I also use mDNS.

7

add a bash script on the remote side and instead just execute the remote bash script to send the WOL packets.

1 Like
8

We still don't know how Wireguard and VXLAN is configured for the client (non-OpenWrt) side. I'm asking again for details on that peer, since a misconfiguration there can prevent this from working.

Especially since I can see something wrong with the VXLAN configuration on the OpenWrt side:

config interface 'vxlan0'
        option proto 'vxlan'
        option tunlink 'wg0'
        option vid '1'
        option port '4789'

You need to add a peeraddr that specifies the IP address of the remote VXLAN endpoint. Otherwise the local VXLAN endpoint won't know what to do for BUM traffic, which is what mDNS and WoL packets are.

The client peer needs to be set up similarly, so we need to see how that peer is configured as well. So far we've only seen the ip a output from that peer, which doesn't show how the wg0 and vxlan0 interfaces are configured.

I'd also like to point out that three different people in this thread has suggested that you remotely generate the WoL packet on the local network instead of tunneling it:

  • @egc suggested using LuCI to generate the WoL packet.
  • @papdee suggested using a bash script that you invoke remotely to generate the WoL packet.
  • I suggested using SSH to directly invoke etherwake to generate the WoL packet.

These are all different ways of doing the same thing. This works with or without the layer 2 tunnel, so just because you need VXLAN for mDNS packets doesn't mean you have to send WoL packets the same way.

9

After using bridging for vxlan0 on the client side, wol worked normally. :grinning:
Now I am trying to make mDNS work as well.

10

I have attached the client's network configuration, but now mDNS still doesn't work, and I don't know what happened.
Basically, I enabled System resolved according to the ArchWiki tutorial.

11

I had a hard time to continue reading after this. If you use a broken LLM which claims knowledge, and come up with falsehoods all the time please state so in your post.

I also know that, that you have to attach a vxlan interface to a bridge because I do so since 2018.

And in addition: if you use vxlan you have to populate the FDB, the forward date base, some how. That's why i.e. EVPN exist, and other mechanism to know the peers and the mac addresses behind that tunnel.

If you just need a layer2 connection then maybe GRE, generic routing encapsulation, is a better choice. How ever you seam to have solved your issue in the meantime anyhow....

1 Like