* Getting IPv6 route advertisements to work over WG @ 2018-08-27 12:14 Roman Mamedov 2018-08-27 13:32 ` netravnen 0 siblings, 1 reply; 6+ messages in thread From: Roman Mamedov @ 2018-08-27 12:14 UTC (permalink / raw) To: wireguard 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting IPv6 route advertisements to work over WG 2018-08-27 12:14 Getting IPv6 route advertisements to work over WG Roman Mamedov @ 2018-08-27 13:32 ` netravnen 2018-08-27 13:53 ` Roman Mamedov 0 siblings, 1 reply; 6+ messages in thread From: netravnen @ 2018-08-27 13:32 UTC (permalink / raw) To: rm, wireguard [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting IPv6 route advertisements to work over WG 2018-08-27 13:32 ` netravnen @ 2018-08-27 13:53 ` Roman Mamedov 2018-08-27 14:46 ` Riccardo Paolo Bestetti 0 siblings, 1 reply; 6+ messages in thread From: Roman Mamedov @ 2018-08-27 13:53 UTC (permalink / raw) To: netravnen; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Getting IPv6 route advertisements to work over WG 2018-08-27 13:53 ` Roman Mamedov @ 2018-08-27 14:46 ` Riccardo Paolo Bestetti 2018-08-27 14:55 ` Matthias Urlichs 2018-08-27 21:14 ` StarBrilliant 0 siblings, 2 replies; 6+ messages in thread From: Riccardo Paolo Bestetti @ 2018-08-27 14:46 UTC (permalink / raw) To: wireguard 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting IPv6 route advertisements to work over WG 2018-08-27 14:46 ` Riccardo Paolo Bestetti @ 2018-08-27 14:55 ` Matthias Urlichs 2018-08-27 21:14 ` StarBrilliant 1 sibling, 0 replies; 6+ messages in thread From: Matthias Urlichs @ 2018-08-27 14:55 UTC (permalink / raw) To: wireguard 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting IPv6 route advertisements to work over WG 2018-08-27 14:46 ` Riccardo Paolo Bestetti 2018-08-27 14:55 ` Matthias Urlichs @ 2018-08-27 21:14 ` StarBrilliant 1 sibling, 0 replies; 6+ messages in thread From: StarBrilliant @ 2018-08-27 21:14 UTC (permalink / raw) To: Roman Mamedov, Riccardo Paolo Bestetti; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-27 21:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-27 12:14 Getting IPv6 route advertisements to work over WG Roman Mamedov 2018-08-27 13:32 ` netravnen 2018-08-27 13:53 ` Roman Mamedov 2018-08-27 14:46 ` Riccardo Paolo Bestetti 2018-08-27 14:55 ` Matthias Urlichs 2018-08-27 21:14 ` StarBrilliant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).