Introduce Wireguard support to bird
Hey everyone, as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know. Regards Janne
On Fri, Jun 07, 2019 at 06:21:42PM +0000, Janne Heß wrote:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
Hi Could you explain what the Wireguard support broadly does (compared to regular route update)? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Fri, Jun 07, 2019 at 06:21:42PM +0000, Janne Heß wrote:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
Hi
Could you explain what the Wireguard support broadly does (compared to regular route update)?
Wireguard ties prefixes to public keys to figure out which peer to send a packet to. This supersedes any regular routing on that interface, so it needs to be done in addition to installing the route on the interface. See https://www.wireguard.com/#cryptokey-routing -Toke
Janne Heß <janne@hess.ooo> writes:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
Hi Janne Awesome that you have taken the time to implement this! I'll let the Bird maintainers comment on the approach of embedding the wireguard netlink library; but I have two other concerns: - As far as I can tell there's nothing preventing Bird from removing AllowedIPs that it did not itself install from an interface, right? - The algorithm is basically O(P*M*N) for inserting N routes on an interface with P peers that each have M existing AllowedIPs. That is not going to scale very far :/ -Toke
On 08.06.19 00:18, Toke Høiland-Jørgensen wrote:
- The algorithm is basically O(P*M*N) for inserting N routes on an interface with P peers that each have M existing AllowedIPs. That is not going to scale very far :/
-Toke
Hi Toke, Could you give me an example for a topology/setup where you have one server with only one wireguard interface, but n peers (sharing a key-pair(?)), connecting to that one server endpoint and have proper routing of the packets? Routing decision then happens in wireguard, but --let me repeat-- this implies that all "clients" share the same key-pair? As far as I have understood wireguard setups I thought that per peer, a server has an individual interface with either specific networks or a 0.0.0.0/0 wildcard and then uses dynamic routing to fill the (os) kernels routing table to reach each client or client-network. Off topic: Does this patch supports unnumbered ospf and bgp? I have not implemented this based on limited knowledge about the boundary condition and what is really needed from a linux perspective. (More info welcomed) Toff topic #2: Was there any progress on implementing/enable multicast support on wireguard interfaces? Just curious. See: https://lists.zx2c4.com/pipermail/wireguard/2016-December/000813.html (as far as "my" google outputs...) Bernd
Bernd Naumann <bena@spreadshirt.net> writes:
On 08.06.19 00:18, Toke Høiland-Jørgensen wrote:
- The algorithm is basically O(P*M*N) for inserting N routes on an interface with P peers that each have M existing AllowedIPs. That is not going to scale very far :/
-Toke
Hi Toke,
Could you give me an example for a topology/setup where you have one server with only one wireguard interface, but n peers (sharing a key-pair(?)), connecting to that one server endpoint and have proper routing of the packets? Routing decision then happens in wireguard, but --let me repeat-- this implies that all "clients" share the same key-pair?
Why would they need to share the same key pair? Each node would have its own key (but yeah, all of their peers would see the same public key from that node).
As far as I have understood wireguard setups I thought that per peer, a server has an individual interface with either specific networks or a 0.0.0.0/0 wildcard and then uses dynamic routing to fill the (os) kernels routing table to reach each client or client-network.
Sure, that is the most common deployment now, but (to me) the whole point of having wg support in a routing daemon is to avoid having to do this :)
Off topic: Does this patch supports unnumbered ospf and bgp? I have not implemented this based on limited knowledge about the boundary condition and what is really needed from a linux perspective. (More info welcomed)
Toff topic #2: Was there any progress on implementing/enable multicast support on wireguard interfaces? Just curious. See: https://lists.zx2c4.com/pipermail/wireguard/2016-December/000813.html (as far as "my" google outputs...)
Don't think so, but as far as I'm concerned, that would be part of the "full" routing-based solution... :) -Toke
On 6/8/19 12:18 AM, Toke Høiland-Jørgensen wrote:
Janne Heß <janne@hess.ooo> writes:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
Hi Janne
Awesome that you have taken the time to implement this!
I'll let the Bird maintainers comment on the approach of embedding the wireguard netlink library; but I have two other concerns:
- As far as I can tell there's nothing preventing Bird from removing AllowedIPs that it did not itself install from an interface, right?
- The algorithm is basically O(P*M*N) for inserting N routes on an interface with P peers that each have M existing AllowedIPs. That is not going to scale very far :/
-Toke
Hi Toke, thanks for your review. Your first observation is correct. Due to differences in semantics, this cannot be implemented in the same way it is implemented in the KRT protocol because AllowedIPs don't have a notion of the proto field. Addressing your second point, the WireGuard netlink interface and library only offer and understand the peers and allowed IPs as a linked list. As we only get each route seperately, we cannot process multiple routes in one run. We're open to suggestions and patches. Regards Janne
Janne Heß <janne@hess.ooo> writes:
On 6/8/19 12:18 AM, Toke Høiland-Jørgensen wrote:
Janne Heß <janne@hess.ooo> writes:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
Hi Janne
Awesome that you have taken the time to implement this!
I'll let the Bird maintainers comment on the approach of embedding the wireguard netlink library; but I have two other concerns:
- As far as I can tell there's nothing preventing Bird from removing AllowedIPs that it did not itself install from an interface, right?
- The algorithm is basically O(P*M*N) for inserting N routes on an interface with P peers that each have M existing AllowedIPs. That is not going to scale very far :/
-Toke
Hi Toke,
thanks for your review.
Your first observation is correct. Due to differences in semantics, this cannot be implemented in the same way it is implemented in the KRT protocol because AllowedIPs don't have a notion of the proto field.
Yeah, not sure what a good way to handle that might be. You could add this capability to the upstream wireguard?
Addressing your second point, the WireGuard netlink interface and library only offer and understand the peers and allowed IPs as a linked list. As we only get each route seperately, we cannot process multiple routes in one run. We're open to suggestions and patches.
Well, there are a couple of options, I guess: - Fix the wireguard netlink interface to work better with insertion/deletion semantics. - Cache the kernel response in a data structure that allows more efficient lookups. Before doing any of this, you may want to wait for feedback on whether this approach to adding the support is the right way to go. Personally, I tend to think that the "right" way to add the support is by introducing a new 'wireguard' protocol type to Bird. But that's up to Ondrej et al, of course :) -Toke
Hi Janne, On 07.06.19 20:21, Janne Heß wrote:
Hey everyone,
as advertised, I have completed the Wireguard support. You might see that I am not really a C expert, but I hope the code is good enough. If you need me to change anything or have additional questions, just let me know.
what is the best practice to run bird with OSPF over Wireguard? In my setup I had to add manually created Link-Local addresses to the Wireguard interfaces to get OSPF to work. Best Regards Bjoern
participants (5)
-
Bernd Naumann -
Bjoern Franke -
Janne Heß -
Ondrej Zajicek -
Toke Høiland-Jørgensen