Not opposed to it, but on the other hand I have no idea how to package it?
I ended up implementing daemons for eg. setting up all the interfaces and routing on the box, because I ran into so many bugs in systemd-networkd that in the end it was impossible to work around them all and I just implemented it from scratch.
So installing the software pretty much takes over your system and turns it into a vpn+firewall unit. ;-)
Not something most users would expect if they find an open source project and install a .deb or something. So I'm not sure if it is advisable to open source it.
> All iptables/nftables/netfilter rules apply.
Rules haven't loaded yet, as per previous reply.
> Either I don't understand what you've written,
> or this is complete nonsense.
The former, I'm sure ;-).
> Probably it'd be easiest to just poke us in #wireguard
Yeah maybe.
> In "kernel-speak" it's a net_device with hard_header_len = addr_len = 0, instantiable via rtnl.
OK.
I actually have an alternative implementation of the GUI lying around where it does handle wg devices like a special device that you can only do IP on.
But it turned out to be a lot of reimplementation of everything (handling IP addresses, routing, configuring interfaces, generating anti-spoofing rules, applying policy, ...) that in the end it turned out to be an unworkable mess.
So right now the code handles wg interfaces like any other "bearer" interface, in other words a bit-bucket you can pour stuff into and it turns up at a peer port on some other box. Obviously that is a bit wrong as it cannot forward L2, so that means there are some features that are unusable (in particular VLAN tagging and VRFs).
(It's also possible that I have just been too eager when selecting wireguard and should have found an L2-compatible VPN system instead. Not sure which one fits the bill though.)
By the way, is there a video available of the talk/session you and GKH and others had recently?
I'd love to learn about wireguard internals by following along a recording of the session.
If the premise "the peer public key is sort of the peer's lladdr" is correct, here's an idea off my chest. (Beware that I am blissfully unaware of wireguard internals, just brainstorming.)
If the peer pubkey identifies the port on the other end, just like a MAC address would identify the NIC on the other end of a switched network;
Then would it be possible to give the kernel the peer pubkey as the lladdr when it asks for a next-hop's lladdr?
If so, all the IP routing stuff could be moved out of wireguard and taken care of by the kernel's IP router.
Without the internal IP routing function, L2 traffic could possibly be forwarded.
If the lladdr field is not large enough, maybe allow the user to give to wg a mapping between fx. a 6-byte locally assigned peer lladdr, and the 32-byte peer pubkey. Or ask Linus to extend the field. ;-)
Could be hidden behind an "l2-mode" flag or something.
In my opinion, being able to forward L2 would help a lot towards building a GUI in a sensible way, but yeah, just an idea.
# ip link add dev wg0 type wireguard
# wg set wg0 listen 0.0.0.0:51820 listen ::/0:51820 private-key /path/to/private-key
# ip link add dev wg0-peer1 type wireguard-peer
# wg set wg0-peer1 local-endpoint wg0 remote-endpoint 209.202.254.14:8172 public-key ABCDEF
Then routing via kernel:
# ip route add 192.0.2.0/24 dev wg0-peer1
And/or layer something else on top:
# ip link add link wg0-peer1 name peer1-vlan100 type vlan id 100
Perhaps enslave that to a VRF:
# ip link set peer1-vlan100 vrf blue
The peering interfaces could also be assigned an MTU that matches the path to each peer, if known:
Thanks!
> Any plans to open source that?
Not opposed to it, but on the other hand I have no idea how to package it?
I ended up implementing daemons for eg. setting up all the interfaces and routing on the box, because I ran into so many bugs in systemd-networkd that in the end it was impossible to work around them all and I just implemented it from scratch.
So installing the software pretty much takes over your system and turns it into a vpn+firewall unit. ;-)
Not something most users would expect if they find an open source project and install a .deb or something. So I'm not sure if it is advisable to open source it.
> All iptables/nftables/netfilter rules apply.
Rules haven't loaded yet, as per previous reply.
> Either I don't understand what you've written, > or this is complete nonsense.
The former, I'm sure ;-).
> Probably it'd be easiest to just poke us in #wireguard
Yeah maybe.
> In "kernel-speak" it's a net_device with hard_header_len = addr_len = 0, instantiable via rtnl.
OK.
I actually have an alternative implementation of the GUI lying around where it does handle wg devices like a special device that you can only do IP on.
But it turned out to be a lot of reimplementation of everything (handling IP addresses, routing, configuring interfaces, generating anti-spoofing rules, applying policy, ...) that in the end it turned out to be an unworkable mess.
So right now the code handles wg interfaces like any other "bearer" interface, in other words a bit-bucket you can pour stuff into and it turns up at a peer port on some other box. Obviously that is a bit wrong as it cannot forward L2, so that means there are some features that are unusable (in particular VLAN tagging and VRFs).
(It's also possible that I have just been too eager when selecting wireguard and should have found an L2-compatible VPN system instead. Not sure which one fits the bill though.)
By the way, is there a video available of the talk/session you and GKH and others had recently?
I'd love to learn about wireguard internals by following along a recording of the session.