Multicast over a wireguard link?

Does Wireguard has a notion of multicast? I would like to eventually replace my current VPN setup with wireguard. I currently run Tinc in switch (layer 2) mode, and run the Babel routing protocol on top.

Babel announces itself via link-local multicast to everyone on the link. Does this work with wireguard? I guess the equivalent semantics would be "send this packet to all known peers"...

-Toke

[Caution: Unfiltered thoughts and ideas, untested from mind to mail. WoT = ahead.]

Hi Toke,

I am on the road so can't test right now. Can you elaborate on babel a = bit? Would you be able to use non-link-local multicast addresses? Let's = call it "routed multicast" for now.

Maybe related/similar case: DHCPv6 =
https://github.com/openwrt/luci/issues/854#issuecomment-261588333

This message is probably not much of help. However, it made me thinking = about deriving solicited node address from the peer public keys would be = theoretically possible (nothing like that is implemented and may not = even be a wise idea at all). In a centralized setup (one server many = road warrios/sites) this should theoretically straightforward.

Not having multicast on VPN links is an inconvenience, especially with = all the zeroconf and mdns devices in our networks sometimes. But = multicast on VPN links can be a pain, too.

One thing you could do, although not very clean, is to unicast-announce = to all /128 IP addresses from your allowd_ips per peer. If babel can do = that or can be modifed to do so. /128 are often the addresses of the = wg-interface on the other end. However, keep in mind that this is a wild = guess and not a clean solution.

Another thing I can't try right now but may be worth playing with is = assigning addresses from the ff-range and see what happens. How well = does the kernel like it and how will wireguard threat these addresses. I = never tried.

A all-nodes multicast will probably not scale well in more complex = setups (some people run many peers on one interface, imagine what = happens then...). However, solicited-node multicast based on a 24bit = hash (blake?) of the public key should reduce the amount of packets that = need to be sent. I wonder how reliable it is to generate EUI64 out of = the public keys and thus provide link-local addresses without any need = for allowed-ips at all for tunnel setup. Wouldn't that be just awesome?

Multicast... keeps me thinking. I'll post again if I come up with = anything that might help.

Cheers,

Dan

PS: Don't take anything for granted. I wrote this done while thinking = about it. Better trust Jason's words, he knows it right.

link.

be

Hi Toke,

Right now, no, there's no multicast. But it wouldn't be that hard to add the ability to add the same allowed-ips entry to multiple peers, and have WireGuard duplicate the message to all of them.

It's not complicated in theory, but I wonder if this would be genuinely useful, and whether or not it'd open up a wormhole of potential issues.

Thoughts?

Jason

The multicast destination address is known, so that should work. Would also serve as a kind of ACL, I guess.

Well, I would certainly limit it to multicast addresses. But other than that it sounds like an excellent idea.

Can wireguard handle routed traffic to an endpoint. I.e. if endpoint A has address 10.0.0.1/32 and endpoint B has a route 'ip route add 10.10.10.1/24 via 10.0.0.1 dev wg0', would the traffic go where it's supposed to?

-Toke

The via isn't relavent, since that only functions to determine which device to send it out of. All the ordinary routing table will do is direct it toward wg0. Once it hits wg0, then the allowed-ips entries are consulted to see where to send it (the "cryptokey routing table"). See sections 2 and 3 of [1].

[1] https://www.wireguard.io/papers/wireguard.pdf

Right, but that means that even if multicast is added, a routing protocol won't be terribly useful, since it can't tell wireguard which subnets lives behind which peers. What I would need is to be able to assign /32s (or IPv6 lladdrs) to the interface for each peer, and have the kernel routing table determine which subnets should go to each of those. My hope was that wireguard could then figure out where to send the packet from the /32s (which would be in the wireguard config, presumably).

-Toke

I currently use OSPF with one interface per peering with link-local ipv4/= ipv6 addresses (AllowedIPs=3D0.0.0.0/0,::/0, ipv4 =3D> 169.254.0.0/16 + l= ifetime 0)

This works fine.

=2E

e