4 ms·

Yeah for sure. Here are some screenshots: https://imgur.com/a/aT8TU https://imgur.com/a/aT8TU There are additional settings on the various detail screens (not

Yeah for sure. Here are some screenshots: https://imgur.com/a/aT8TU https://imgur.com/a/aT8TU There are additional settings on the various detail screens (not shown), such as wg peers. Vuejs turned out to be quite cool. If you plug in a new linecard (like an USB Ethernet adapter for example), it pops up in the GUI immediately and is ready to be named, configured, used etc. ;-) > WireGuard listens on all interfaces [...] > If a packet makes it to your system and the authtag is validated, it doesn't matter through what interface it arrived; it's legit. Yeah but you try telling the person administering the combined firewall/vpn/router box that his/her firewall rules are no longer in control of what traffic is allowed in or not. If it happens to be destined to the wireguard port, the rules are for naught. I should probably explain that there's a small firewall in there too. It uses nftables to compile user rules via eBPF to machine code. The way these things normally work, as I understand it, is that forwarding is disabled during boot, and only when the firewall policy has been successfully loaded is forwarding enabled via a sysctl flag. The firewall handles simple stuff like masquerading and destination NAT. Advanced functionality happens by handing off datagrams from the firewall to userspace or kernelspace daemons like wireguard. Long story short (too late, sorry), you can't have stuff listening on 0.0.0.0/0 and ::/0 because it is unaffected by the forwarding flag and hence the firewall rules are violated during boot (and potentially for an unbounded time period if the policy fails to load for some reason). Anyway, turned out it was really easy to fix by patching the wireguard source code. > WireGuard is layer 3 -- IP -- not Ethernet, which is how I believe tunnels should be made. That's a completely fair point. I'm just talking from a user's perspective, where what pops up on one's box after installation is in fact a virtual ethernet device, in kernel-speak. When the device then drops L2 frames, it can be a bit unexpected to someone unfamiliar with that specific philosophy. Is there any recommended workaround if one wants routers to see each other on the link layer? Some kind of encapsulation maybe? > WireGuard isn't Ethernet; it's IP. It doesn't use MAC addresses. It has public keys instead. Yeah I guess the public key sort of is the link layer address in this case. > a better place to discuss is probably #wireguard on Freenode, or the mailing list I was tempted to ask why the wg device shows up with the POINTOPOINT flag, when it is clearly a multipoint device, but I'll save it for the IRC channel. ;-)

zx2c4 9y ago
> Yeah for sure. Here are some screenshots: Looks real nice. Any plans to open source that? > Yeah but you try telling the person administering the combined firewall/vpn/router box that his/her firewall rules are no longer in control of what traffic is allowed in or not. No, this is not correct. All iptables/nftables/netfilter rules apply. My comment was strictly related to the fact that it listens on 0.0.0.0, but you're still in full control of all firewalling in every way. > stuff listening on 0.0.0.0/0 and ::/0 is unaffected by the forwarding flag Either I don't understand what you've written, or this is complete nonsense. This doesn't correspond with anything real I can fathom. Probably it'd be easiest to just poke us in #wireguard on Freenode, and we can try to figure out together whatever behavior you're seeing. In addition to me being in there to discuss WireGuard-related things, there are some nftables experts there too, who will probably have insights into your firewall configuration. > is in fact a virtual ethernet device, in kernel-speak. It's actually not an ethernet device. In "kernel-speak" it's a net_device with hard_header_len = addr_len = 0, instantiable via rtnl. > When the device then drops L2 frames All L3 devices reject L2 frames. There are quite a few L3 devices, in fact, not just WireGuard.
- phragma 9y ago
  > Looks real nice. 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.

zx2c4 9y ago

> Yeah for sure. Here are some screenshots: Looks real nice. Any plans to open source that? > Yeah but you try telling the person administering the combined firewall/vpn/router box that his/her firewall rules are no longer in control of what traffic is allowed in or not. No, this is not correct. All iptables/nftables/netfilter rules apply. My comment was strictly related to the fact that it listens on 0.0.0.0, but you're still in full control of all firewalling in every way. > stuff listening on 0.0.0.0/0 and ::/0 is unaffected by the forwarding flag Either I don't understand what you've written, or this is complete nonsense. This doesn't correspond with anything real I can fathom. Probably it'd be easiest to just poke us in #wireguard on Freenode, and we can try to figure out together whatever behavior you're seeing. In addition to me being in there to discuss WireGuard-related things, there are some nftables experts there too, who will probably have insights into your firewall configuration. > is in fact a virtual ethernet device, in kernel-speak. It's actually not an ethernet device. In "kernel-speak" it's a net_device with hard_header_len = addr_len = 0, instantiable via rtnl. > When the device then drops L2 frames All L3 devices reject L2 frames. There are quite a few L3 devices, in fact, not just WireGuard.

phragma 9y ago
> Looks real nice. 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.