7 ms·

> I did a vuejs/html5 web interface for wireguard recently and found it delightful to work with. Sounds cool. Care to share? I'd love to see people's usage. >

by zx2c4 9y ago

> I did a vuejs/html5 web interface for wireguard recently and found it delightful to work with. Sounds cool. Care to share? I'd love to see people's usage. > - there is no option to specify listener ip+port tuples WireGuard listens on all interfaces, because packets themselves are authenticated cryptographically. 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. WireGuard also is able to reply using the destination address and interface of the incoming packet as the source address and interface of the outgoing packet, which is the other common usage of binding to particular IP addresses. > - logical sub-interfaces work fine, unless they happen to emit a vlan tag WireGuard is layer 3 -- IP -- not Ethernet, which is how I believe tunnels should be made. Instead of vlans, just add more tunnels if you need. > - almost every virtual ethernet device in the kernel calls eth_hw_addr_random(dev); WireGuard isn't Ethernet; it's IP. It doesn't use MAC addresses. It has public keys instead. > - "allowed-ips" cannot be turned off; Yes: the crypto key routing is the central idea of WireGuard. You establish a strong binding between public key and internal tunneled IP address, and then all your rules and policies on top of that suddenly become quite simple. > - when one "allowed-ips" setting is added to a peer, wg may silently remove "allowed-ips" on another, unrelated peer Peers can't share internal tunneled IP addresses; otherwise, there wouldn't be strong binding to public keys, nor efficiency of sending outbound packets. So if you assign an already assigned one to another peer, the presumption is that you want to _move_ the allowed IP. By always going with the newer future demand, and not erroring and staying with the old one, we ensure forward progress on your overall changes to policy. IOW, if you're changing things, we want the state to look like what you're changing it to. If you have any additional questions at this level (a great level, thanks for those), a better place to discuss is probably #wireguard on Freenode, or the mailing list -- https://lists.zx2c4.com/mailman/listinfo/wireguard https://lists.zx2c4.com/mailman/listinfo/wireguard

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
phragma 9y ago
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.

by zx2c4 9y ago

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

phragma 9y ago

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.