Re: Multicast over a wireguard link?

Re: Multicast over a wireguard link?

[Jason A. Donenfeld]

On Tue, Dec 20, 2016 at 7:40 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> 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).

Ahh, I see. In this case, the routing protocol needs to update
WireGuard, not the kernel's routing table. This forces you to
re-envision your routing protocol in terms of "which public key should
get which routes?" which strikes me as an authenticity improvement.

Re: Multicast over a wireguard link?

[Toke Høiland-Jørgensen]

On 20 December 2016 19:43:15 CET, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>On Tue, Dec 20, 2016 at 7:40 PM, Toke Høiland-Jørgensen <toke@toke.dk>
>wrote:
>> 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).
>
>Ahh, I see. In this case, the routing protocol needs to update
>WireGuard, not the kernel's routing table. This forces you to
>re-envision your routing protocol in terms of "which public key should
>get which routes?" which strikes me as an authenticity improvement.

Hmm, longer term carrying public keys in the routing protocol might be viable, but getting to there is not trivial. 

However a netlink interface that says, essentially, "add traffic going to subnet A to the same peer that has address X". That would turn wireguard into a normal routing table (conceptually, at least). If the same netlink interface could be used, it wouldn't even be necessary to modify the routing daemon...

Multicast over a wireguard link?

[Toke Høiland-Jørgensen]

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

Re: Multicast over a wireguard link?

[Dan Lüdtke]

[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.

> On 20 Dec 2016, at 15:53, Toke H=C3=B8iland-J=C3=B8rgensen =
<toke@toke.dk> wrote:
>=20
> 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.
>=20
> 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"...
>=20
> -Toke
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Multicast over a wireguard link?

[Jason A. Donenfeld]

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

Re: Multicast over a wireguard link?

[Toke Høiland-Jørgensen]

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> 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.

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

> 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.

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

Re: Multicast over a wireguard link?

[Jason A. Donenfeld]

On Tue, Dec 20, 2016 at 7:19 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> 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?

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

Re: Multicast over a wireguard link?

[Toke Høiland-Jørgensen]

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> On Tue, Dec 20, 2016 at 7:19 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t=
oke.dk> wrote:
>> 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?
>
> 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].

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

Re: Multicast over a wireguard link?

[Jörg Thalheim]

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.

On 2016-12-20 15:53, Toke H=F8iland-J=F8rgensen wrote:
> 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=
=2E
> Does this work with wireguard? I guess the equivalent semantics would b=
e
> "send this packet to all known peers"...
>
> -Toke
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard