[RFC] gluon-mesh-vpn-wireguard ? #1058
Comments
So a wireguard package would be called "gluon-mesh-vpn-wireguard". We could add such a package, but I don't like the GRE hackery. Let's rather work on adding wireguard support for Babel when that is merged, so we can use the Layer 3 tunnel directly. |
|
thats why i am asking beforehand ;) |
viisauksena
changed the title
|
Well, it would be a good idea to start with a clean wireguard l3
integration now. babel is underway. see #934
|
rotanid
changed the title
|
@christf , didnt get your last message, you mean we should work on a gluon-mesh-vpn-wireguard ?
|
|
Just a side note ... I already asked the wireguard-author several month ago if he is planning or might consider to add a tap- instead of a tun-mode for wireguard. He immediately responded, he is not considering to add a tap-mode because he don't think that L2 tunnelling is often used and most of the time unneeded, furthermore he wants to keep it as small as possible and don't blow it up with more stuff which is rarely needed. So if someone might thought about waiting for a tap-mode to be implemented in wireguard I have to disappoint you, this seem to be not happening. But maybe we want to ask the author once again, if it's possible to make 1:n connections, like in fastd possible. Well, and I'm still curious, why is fastd not pushing to be added to the kernel or maybe just as kernel module? Would that be so much work and not the effort worth? :) |
|
@RubenKelevra We're aware of these limitations. 1:n connections are possible in TAP mode only, not in TUN mode, so wireguard can't support it either. The current plan is to add a gluon-mesh-vpn-wireguard module after Babel support is merged (a Layer 3 tunnel should be enough for Babel). I don't see the need for a fastd kernel module as wireguard exists now. |
|
Hey Matthias,
@RubenKelevra We're aware of these limitations. 1:n connections are
possible in TAP mode only, not in TUN mode, so wireguard can't
support it either. The current plan is to add a
gluon-mesh-vpn-wireguard module after Babel support is merged (a
Layer 3 tunnel should be enough for Babel).
I don't see the need for a fastd kernel module as wireguard exists
now.
But there is not an actual limitation for a L3 tunnel to be only 1:1,
is it?
I think OpenVPN supports L3 tunnels 1:n very fine. So the question is,
why shouldn't wireguard do this as well? :)
Did somebody already ask the author for this feature?
|
|
@RubenKelevra OpenVPN uses ugly hacks, there are only two ways it can work:
None of these solutions are compatible with dynamic routing as used in our mesh networks. The proper solution is to use 1:1 tunnels. |
|
Hey Matthias,
@RubenKelevra OpenVPN uses ugly hacks, there are only two ways it can
work: 1. When only a single address assigned by OpenVPN itself is
assigned to a peer 2. When the subnets routed to a specific peer are
explicitly configured in the OpenVPN config Otherwise, OpenVPN can't
know what peer a specific IP address lies behind, and "via" routes
don't work because they rely on a L2 the "gateway" can reached over.
None of these solutions are compatible with dynamic routing as used
in our mesh networks. The proper solution is to use 1:1 tunnels.
Yeah, OpenVPN isn't a very good example, because it's way to hacky in
every way.
Since Wireguard uses it's own protocol for communication, wouldn't it
be possible do something similar to dhcp on a connect after
authenfication?
Then Wireguard knows each tunnel-IP pair without the need for that
much interfaces and the scripted setup stuff for each new node.
Because one interface per Freifunk-node doesn't look like a very
favoritable solution to me either. We have over 1200 nodes configured at
the moment, which means we get a lot of interfaces on each server...
Or is there any limitation which would make it impossible for babel to
use this?
|
|
It's really about Babel needing to add arbitrary routes to arbitrary peers. A L3 interface only allows adding interface routes, the "via" address of such routes is ignored completely; this makes it impossible to define the destination peer when multiple peers are connected behind a single interface. Using 1:1 tunnels is the a way to solve this without hacks (and I don't know why we're even discussing this; 1:1 tunnels are a sane solution as long as there's tooling to automatically establish large numbers of such tunnels, like there is with Tunneldigger for L2TP). |
|
It's really about Babel needing to add arbitrary routes to arbitrary
peers. A L3 interface only allows adding interface routes, the "via"
address of such routes is ignored completely; this makes it
impossible to define the destination peer when multiple peers are
connected behind a single interface.
Using 1:1 tunnels is the a way to solve this without hacks (and I
don't know why we're even discussing this; 1:1 tunnels are a sane
solution as long as there's tooling to automatically establish large
numbers of such tunnels, like there is with Tunneldigger for L2TP).
Alright, thanks, I had no time to deeply look into Babel. But this
sounds absolutly reasonable.
Do you have tested such a large scale setup out? Means wireguard
establishing thousands of tunnels while babel is using them? :)
Just don't want to run into trouble if I'm the first to test that out,
while everybody else is just using 200 tunnels per server. :)
|
|
on wireguard side there will only be one tunnel iface serverside, which is fine when all the packets are routet. You may dig deeper into wireguard. the handling will be similar to fastd, where 1 "server" has many peers. but all peers mostly only one server. |
|
@viisauksena thanks for your comment. Well, but if so, we still need 1:1 tunnels for babel if I understood NeoRaider correctly. I think I have to dig deeper in both topics, Babel as well as Wireguard, before I ask further stupid questions here. :) Well, thanks for your headup, I guess I will start to just follow this discussion until I had the time to read both manuals/documentations. But I want to make one thing clear, I loved the batman-adv approach for the one-net approach, because local devices can find eachother, if we can implement efficient multicast-routing as well as node-based IGMP-snooping and multicast-to-unicast on the wifi-side with Babel itself I'm sure we will change to Babel. Wireguard just looks good because it have strong crypto and is fast, which is currently a HUGE bottleneck for us. Fastd always served us well, so I think I'll miss it :) |
|
@Neoraider I've talked a bit to a guy who is currently developing babeld. He said that WireGuard is currently incompatible to babeld because babeld needs a multicast-able transport which WireGuard doesn't provide. But support for unicast-only links are in active consideration because they want to implement TLS-security between peers. Additionally we can use gretap or similar above WireGuard to make it compatible with babeld. |
|
I have looked at l3roamd and we don't need multicast as it can handle the routes. WireGuard is great (40 MBit/s Batman <-> GRETAP <-> WireGuard). I'm working on getting it supported right after Babel (and also with Babel)... |
|
l3roamd + babeld depend on working multicast for route distribution at the moment. Even with the unicast patchset, not all multicasts by babeld are replaced. |
|
The WireGuard architecture is very simple. Patching WireGuard to support multicast should be no problem. |
|
I have started work to integrate wireguard as l3 VPN based on the code above. The code will shortly be in my christf_next branch on https://github.com/christf/gluon/tree/christf_next There is a lot to be done. The scripts need to be replaced by proper integration and support form ultiple peers needs to be set up. |
|
From an IPSec point of view, defining an l2tp pseudowire on top of wireguard appears to be reasonable - just like IPSec offers a a transport-mode. As an alternative, adding a vxlan layer using unicast-endpoints is consistent with gluon's 802.11s configuration. |
|
@yanosz Before fiddling around with L2TP/VXLAN over WireGuard please consider a fork of WireGuard with L2 support as it is very straightforward. WireGuard can easily be adopted to our needs. |
|
What's more likely to happen? Someone porting wireguard to L2 or someone porting fastd to kernel module? |
|
@kpanic23 If the person considers security and maintainability aspects porting WireGuard to L2, but if he or she just wants a q&d solution porting fastd to kernel space. zx2c4 does not consider adding L2 support until WireGuard is merged into mainstream kernel, but in the long run L2 could be merged. We need more people capable of writing C/kernel code and both quests should be a good starting point. |
|
Maybe a project for the upcoming GSoC? |
|
this issue here will be done by #1534 - for babel/L3 meshes. |
|
twmic: In the meantime @johnnybee created a wireguard implementation using gretap.
I guess, that this is WIP atm. At KBU's community day in February this year we discussed open todos (docs, e.g. why gretap instead of l2tp/tunneldigger) and I guess, that johnybee is working on that. |
|
I've a poc implementation of layer 2 WireGuard, but I assume I won't have free-time to finish it until the end of the year and I'd like to get some funding to do it properly. E.g. 4-way-handshake for perfect forward privacy hiding of node's identities and solving the time problem with that. I also have a WireGuard/GRETAP implementation, but I wasn't happy with the MTU. |
|
It would be interesting to hear, how the latest gretap or layer 2 implementations have progressed in favour of #1534 meanwhile. I'd be very gracious to see easily configurable and secure IPv6 tunnels in the future. |
|
We already have VXLAN on the gluon Routers. @NeoRaider @CodeFetch is that not a way to overcom the missing layer2 support of wireguard? |
|
@2tata I really don't like such a bodge job. You know... It's not that we are unable to do it right. I have a GRE-WireGuard-Patch lying around here for years, but a tunnel in a tunnel means too much overhead/MTU issues. In my view the right thing to do is to just create a layer 2 tunnel based on WireGuard. Originally I've talked to Jason Donenfeld and he said it was okay to integrate layer 2 support in WireGuard, but then it became upstream and the API is now fixed. Thus we would need to create an own tunnel interface. I know how to do it, but I don't have any time for it. At some point this was working except some packet length issues which would need further investigation. The hard problem is to bring it upstream. By all means at the moment I don't think it makes any sense to put effort into WireGuard as lemoer and I are currently evaluating io_uring. io_uring allows to do IO in an asynchronous manner without a lot of context switches. To be clear: We hope for fastd to double its throughput. |
|
@2tata Do you want to join us in our evaluation? This is the current working state (there is a commit missing for fixing a memory leak): https://github.com/lemoer/fastd/commits/socket To give you a brief overview of what we are currently examining: |
|
Well, the obvious point is to route non-local traffic using wireguard instead of establishing yet another overlay for batman-adv to underperform. Face it; batman-adv is not meant overlay networks. Most networks have to deal with traffic addressing the internet anyway. Wireguard is built for this, VPN providers offer this service and its about gluon to create such a setup. You can have batman-adv using an overlay ontop of an overlay. But ... trying to make this performing is squaring circles. |
|
Little update on fastd with io_uring: It works with kernel 5.7+ and will increase the throughput by at least 20%. Unfortunately it won't work with an older kernel version and OpenWrt master is on 5.4 at the moment. Thus we need to be patient. Here is the patched branch: https://github.com/CodeFetch/fastd/tree/final |
|
As its not yet mentioned here: |
In case it's not known @freifunkMUC we did exactly this. And it's now also implemented in Gluon. |
do we want to have an official gluon-mesh-wireguard?
similar to mesh-vpn mesh-tunneldigger and mesh-babel ...
ive done this one and it is working pretty fine.
this questions nail down the old #816
if such a packet is needed and if it would be merged.
https://github.com/viisauksena/gluon-mesh-wireguard
actually it reads site.conf (only one server)
it has config-mode entry
generate a key/ipv6 pair and shows it at the end of configmode
it only loads if br-wan has real uplink
edit translatet whole issue 1to1
The text was updated successfully, but these errors were encountered: