Getting IPv6 route advertisements to work over WG

Getting IPv6 route advertisements to work over WG

[Roman Mamedov]

Hello,

I am trying to get IPv6 link-local IPs and route advertisements to work over
WG. The reason is not for the usual case of address autoconfiguration, but to
use RA as a dynamic routing protocol of sorts, as it can distribute routes --
or in case of WG (where routes need to be static in AllowedIPs), act as a
keep-alive protocol.

Example use: a host can be connected to a network via a number of independent
routers (and separate WG tunnel to each); in case one of the routers goes
down, the route entry that it was sending via RA times out, so the host will
automatically use the other one(s) to reach that network. It would look
similar to this:

# ip -6 route
...
fd00::/32 via fe80::be:a0ff:fe18:4aac dev wg1 proto ra metric 1024  expires 30sec pref medium
fd00::/32 via fe80::e8:4fff:fe94:2d7f dev wg2 proto ra metric 1024  expires 119sec pref medium
fd00::/32 via fe80::43:31ff:fec0:da97 dev wg3 proto ra metric 1024  expires 86360sec pref low
...

What works:

  * manually assigning link-local(LL) IPs on both sides of a WG tunnel
    (fe80:[somethingrandom]/64 scope link);
  * any normal communication over these LL IPs (assuming they are also present
    in AllowedIPs);
  * running RADVD with WG link as one of its interfaces;
  * explicitly requesting and receiving a RA, via using 'rdisc6' while specifying the
    other side's LL IP;

What doesn't:

  * it appears multicast not supported, so anything involving
    multicast, as in automatically requesting RAs on the kernel side, or
    manually with 'rdisc6' but without specifying peer's LL:

      # rdisc6 wg3
      Soliciting ff02::2 (ff02::2) on wg3...
      Sending ICMPv6 packet: Required key not available

I found discussion[1], but it is unclear what is the outcome. In any case, I
would like to add my vote to please add some kind of multicast support, even
if just as a dumb broadcast for now. It would work just fine for a lot of
cases; don't know about others, but my WG networks tend to include at most 2-3
hosts each (but there's a lot of independent networks).

[1] https://lists.zx2c4.com/pipermail/wireguard/2017-April/001177.html

-- 
With respect,
Roman

Re: Getting IPv6 route advertisements to work over WG

[netravnen]

[-- Attachment #1.1: Type: text/plain, Size: 2655 bytes --]

Dear Roman,

When using multicast over WireGuard, would it not be more viable to use
an extra encapsulation layer to run multicast inside of?

I am specifically thinking of running either GRE or L2TPv3 over wgX.

Christoffer

From: Roman Mamedov
Sent: Mon, Aug 27, 2018, 14:14 +0200 (Romance Daylight Time)
Subject: Getting IPv6 route advertisements to work over WG

> Hello,
> 
> I am trying to get IPv6 link-local IPs and route advertisements to work over
> WG. The reason is not for the usual case of address autoconfiguration, but to
> use RA as a dynamic routing protocol of sorts, as it can distribute routes --
> or in case of WG (where routes need to be static in AllowedIPs), act as a
> keep-alive protocol.
> 
> Example use: a host can be connected to a network via a number of independent
> routers (and separate WG tunnel to each); in case one of the routers goes
> down, the route entry that it was sending via RA times out, so the host will
> automatically use the other one(s) to reach that network. It would look
> similar to this:
> 
> # ip -6 route
> ...
> fd00::/32 via fe80::be:a0ff:fe18:4aac dev wg1 proto ra metric 1024  expires 30sec pref medium
> fd00::/32 via fe80::e8:4fff:fe94:2d7f dev wg2 proto ra metric 1024  expires 119sec pref medium
> fd00::/32 via fe80::43:31ff:fec0:da97 dev wg3 proto ra metric 1024  expires 86360sec pref low
> ...
> 
> What works:
> 
>   * manually assigning link-local(LL) IPs on both sides of a WG tunnel
>     (fe80:[somethingrandom]/64 scope link);
>   * any normal communication over these LL IPs (assuming they are also present
>     in AllowedIPs);
>   * running RADVD with WG link as one of its interfaces;
>   * explicitly requesting and receiving a RA, via using 'rdisc6' while specifying the
>     other side's LL IP;
> 
> What doesn't:
> 
>   * it appears multicast not supported, so anything involving
>     multicast, as in automatically requesting RAs on the kernel side, or
>     manually with 'rdisc6' but without specifying peer's LL:
> 
>       # rdisc6 wg3
>       Soliciting ff02::2 (ff02::2) on wg3...
>       Sending ICMPv6 packet: Required key not available
> 
> I found discussion[1], but it is unclear what is the outcome. In any case, I
> would like to add my vote to please add some kind of multicast support, even
> if just as a dumb broadcast for now. It would work just fine for a lot of
> cases; don't know about others, but my WG networks tend to include at most 2-3
> hosts each (but there's a lot of independent networks).
> 
> [1] https://lists.zx2c4.com/pipermail/wireguard/2017-April/001177.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Getting IPv6 route advertisements to work over WG

[Roman Mamedov]

On Mon, 27 Aug 2018 15:32:49 +0200
netravnen@gmail.com wrote:

> When using multicast over WireGuard, would it not be more viable to use
> an extra encapsulation layer to run multicast inside of?
> 
> I am specifically thinking of running either GRE or L2TPv3 over wgX.

I know people run VXLAN or other L2 tunneling protocols over WG. I suppose
you can call that "viable" as in "it can work", but it's a horrible workaround
for the lack of better solution, nothing more. For instance the overhead
reaches comical levels:

  TCP
    over IP
      over Ethernet
        over VXLAN
          over UDP
            over IP
              over Wireguard
                over UDP
                  over IP 
                    over Ethernet

Add more fun if you use something else such as PPPoE for Internet connection,
or a 6in4 tunnel for IPv6. At some point the whole thing will break down
because you can no longer fit 1280-byte packets into innermost MTU, and IPv6
won't work.

Not to mention the additional management overhead of an inner L2 tunneling
layer.

Now, if WG would support L2 mode natively (say, with AllowedMACs instead of
AllowedIPs) it would be awesome and that would solve a great number of other
issues as well. But since that appears to be unlikely, and since RAs already
mostly work, with just one piece missing, I hope at least that piece gets
dropped in at some point, and that we aren't stuck at least for this use case
with "more viable" tunneling workarounds forever.

-- 
With respect,
Roman

RE: Getting IPv6 route advertisements to work over WG

[Riccardo Paolo Bestetti]

I laughed in my head. :)

For what my two cents are worth, L2 WireGuard would have its (limited) use =
cases, but nothing beats having a simple and effective mono-purpose protoco=
l like we do now. Everything else can be solved with OpenVPN or appropriate=
 SDN techniques running on top of WG.

<ot>
And about that, I think that out-of-band comms support would be a very nice=
 addition to the protocol. The tunnel could be initially established with n=
o tunnel addresses, but it could provide the ability for setup scripts on e=
ach side to talk to each other to set up routing, addresses, firewalls, etc=
. This would allow more complex setups, but would avoid adding all the comp=
lexity/edge cases/etc. to WireGuard.
</ot>

Regards,
Riccardo

-----Original Message-----
From: WireGuard <wireguard-bounces@lists.zx2c4.com> On Behalf Of Roman Mame=
dov
Sent: luned=EC 27 agosto 2018 15:53
To: netravnen@gmail.com
Cc: wireguard@lists.zx2c4.com
Subject: Re: Getting IPv6 route advertisements to work over WG

On Mon, 27 Aug 2018 15:32:49 +0200
netravnen@gmail.com wrote:

> When using multicast over WireGuard, would it not be more viable to=20
> use an extra encapsulation layer to run multicast inside of?
>=20
> I am specifically thinking of running either GRE or L2TPv3 over wgX.

I know people run VXLAN or other L2 tunneling protocols over WG. I suppose =
you can call that "viable" as in "it can work", but it's a horrible workaro=
und for the lack of better solution, nothing more. For instance the overhea=
d reaches comical levels:

  TCP
    over IP
      over Ethernet
        over VXLAN
          over UDP
            over IP
              over Wireguard
                over UDP
                  over IP=20
                    over Ethernet

Add more fun if you use something else such as PPPoE for Internet connectio=
n, or a 6in4 tunnel for IPv6. At some point the whole thing will break down=
 because you can no longer fit 1280-byte packets into innermost MTU, and IP=
v6 won't work.

Not to mention the additional management overhead of an inner L2 tunneling =
layer.

Now, if WG would support L2 mode natively (say, with AllowedMACs instead of
AllowedIPs) it would be awesome and that would solve a great number of othe=
r issues as well. But since that appears to be unlikely, and since RAs alre=
ady mostly work, with just one piece missing, I hope at least that piece ge=
ts dropped in at some point, and that we aren't stuck at least for this use=
 case with "more viable" tunneling workarounds forever.

--
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Getting IPv6 route advertisements to work over WG

[Matthias Urlichs]

On 27.08.2018 16:46, Riccardo Paolo Bestetti wrote:
> The tunnel could be initially established with no tunnel addresses,

It could also be initially established with one non-forwarded tunnel
address, allowing you to converse through the tunnel with standard
tools, and without adding unnecessary complexity to WG.

Also, keep in mind that you need an initial off-link transaction anyway,
to exchange public keys. You can exchange whatever else needs exchanging
at the same time.

-- 
-- Matthias Urlichs

Re: Getting IPv6 route advertisements to work over WG

[StarBrilliant]

On Tue, Aug 28, 2018 at 12:46 AM Riccardo Paolo Bestetti
<riccardo.kyogre@live.it> wrote:
>
> I laughed in my head. :)
>
> For what my two cents are worth, L2 WireGuard would have its (limited) us=
e cases, but nothing beats having a simple and effective mono-purpose proto=
col like we do now. Everything else can be solved with OpenVPN or appropria=
te SDN techniques running on top of WG.


Hello,

At first, I would like to kindly invite you to search for images with
keyword "three layer network design" (if you lucky to not have the
painful experience of building a datacenter network,) so you would
know what I am talking about.

L2 WireGuard, if exists, can be very important for a "Core Layer" of a
SD-WAN network to run. That is to say, any node may process an IP
packet with any source or destination address, performing routing
decision according to BGP or other routing protocols, and send the
packet to any other node.

Please keep in mind that, in this kind of network, any node must have
an AllowedIPs=3D0.0.0.0, ::/0 to work. The trust model of a Core Layer
network is that, spoofed IP address should already be checked at
Access Layer so no other check need to be done. And we also have AEAD
cipher so even if the attacker knows the IP address of our core
router, they can not break in.

In current version if WireGuard, in order to set up the Core Layer, we
either need to:
- Establish N*(N-1) WireGuard links across N nodes
- Run network virtualization technologies on top of Wireguard like:
VXLAN / NVGRE / Multicast GRE </del>(oops I forgot Wireguard does not
support multicast)</del>

OpenVPN does not count since it sends all packets to the center, not
considered as a mesh network.


Here comes the question: Do we really need a MAC layer for routing?

Remember the past when we set up GRE tunnels over IPsec, running BGP
over it, we do not have MAC layer so we need to establish N*(N-1)
tunnels between nodes. We used OpenNHRP to discovery and build up the
tunnels automatically. This configuration is named DMVPN by Cisco and
is kind of baseline implementation in terms of SD-WAN.

Since we need OpenNHRP discovery, the discovery overhead is no less
than performing ARP / NDP. The MTU for this setup is 1406 with NAT
traversal (may vary). Additionally the numerous tunnels does not share
a common interface name so we need to generate firewall rules
automatically or use wildcard if supported.

>From the fact that Linux performs routing by sending packets with the
original L3 address, but modified L2 address, we need sort of L2
mechanism for a mesh to share a same interface name. I think the
easiest L2 we can have is a MAC layer. This only adds 14 bytes to MTU
overhead and we still have 1440 bytes, much larger than 1406.

Also switching from L3 to L2 does not actually make Wireguard
complicated. L2 is the same as L3, except for we changed IPv4 / IPv6
header to MAC header. And we still can perform security check with
AllowedMACs.


> <ot>
> And about that, I think that out-of-band comms support would be a very ni=
ce addition to the protocol. The tunnel could be initially established with=
 no tunnel addresses, but it could provide the ability for setup scripts on=
 each side to talk to each other to set up routing, addresses, firewalls, e=
tc. This would allow more complex setups, but would avoid adding all the co=
mplexity/edge cases/etc. to WireGuard.
> </ot>

The DMVPN example above is a perfect example for out-of-band comms. I
think it is worse than having a MAC layer, seriously.


On Mon, Aug 27, 2018 at 11:54 PM Roman Mamedov <rm@romanrm.net> wrote:
> I know people run VXLAN or other L2 tunneling protocols over WG. I suppos=
e
> you can call that "viable" as in "it can work", but it's a horrible worka=
round
> for the lack of better solution, nothing more. For instance the overhead
> reaches comical levels:

It reduces the inner MTU to 1390. I provide this value for convenience.


Best regards,
StarBrilliant