5 ms·
Things I wish WireGuard supported out of the box: - Logging of peer IPs when they initially connect or change (yes, you can do this with module flags, but it s
by candiddevmike 4y ago
Things I wish WireGuard supported out of the box:
- Logging of peer IPs when they initially connect or change (yes, you can do this with module flags, but it should come out of the box).
- Tieing WireGuard private keys to a source IP. As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect.
- More control over DNS resolution for endpoints. I want WireGuard to periodically refresh the endpoint IP when I change networks, for instance.
- ericpauley 4y ago> I want WireGuard to periodically refresh the endpoint IP when I change networks, for instance. Out of curiosity, why do you want this?
- candiddevmike 4y agoSplit DNS, where WireGuard may resolve an endpoint differently on a LAN vs internet. Also for IPv4/IPv6 roaming--if WireGuard resolves an IPv6 address but moves to a non IPv6 network, the peer will never connect as far as I know.
- dinosaurdynasty 4y agoIt's not (and shouldn't be) possible to do it in the kernel module, but it's not too hard to write a cronjob/daemon if you really need it. It'd definitely be nice if wg-quick and the official apps supported it, though.
- cgb_ 4y agoI see this when my equipment roams back into my private network and the wireguard server is inside that LAN. It can be solved by NAT'ing packets arriving on your edge router's inside interface, destinated to your outside IP, back to the inside wireguard server IP. Alternatively if your client is Linux, there is: https://github.com/WireGuard/wireguard-tools/tree/master/contrib/reresolve-dns https://github.com/WireGuard/wireguard-tools/tree/master/con...
- matthewaveryusa 4y agowrt the IP not being enforced, do you mean different endpoints can require different IPs, or a client can connect to an endpoint with a different IP configured and it's all good? Last time I tested, if you set one IP per user in your wireguard config, that user must connect with that IP.
- candiddevmike 4y agoI believe you're referring to AllowedIPs, which is more around the IPs allowed over the tunnel. I'm talking about the non tunnel source IP of the peer. If you can copy a peers key and use the right AllowedIPs, nothing stops you from impersonating a peer. Being able to lock down peers to a source IP would fix this.
- matthewaveryusa 4y agoI think that goes against the tenant of wireguard working well while roaming. In general the concept of an identifying ip (outside of wireguard) will only lead to problems: devices can have multiple ips, and also share ips in the case of NAT/CGNAT. In my experience it's never been worth the trouble (again excluding wireguard)
- candiddevmike 4y agoYour EC2 instance probably shouldn't be roaming to Russia though, right?
- bongobingo1 4y agoYou already have to open your fw for wg traffic, doesn't seem too obnoxious to just allow/drop there.
- yardstick 4y agoDeny by default and Defense in depth are good security approaches in many organisations. I may have a critical server that only comes from 1-2 known, static, IPs. Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.
- couchand 4y ago> As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect. Yes WireGuard roams, which is the right behavior usually. What's your use case where an otherwise valid encrypted packet should be rejected based on source ip? Could you use ufw?
- candiddevmike 4y agoMostly laziness. If I'm already giving WireGuard an IP via Endpoint, why not have it locked down to that by default? Isn't that what an end user would expect? Otherwise I have to put that IP in multiple places (WireGuard, nftables, etc).
- couchand 4y agoThe two most common topologies I've seen for WireGuard are: 1) Client-server, where the client is behind NAT and the server is publicly available at some DNS. The client specifies the server by hostname as the endpoint, and the server doesn't bother specifying an endpoint. Client roams when they switch networks, server roams when they roll over the server, everybody is happy. 2) Peer-to-peer, where the nodes are directly addressable by IP address, whether by public IP or private virtual private IP. In this case, the node dialing in sets an endpoint of the node being dialed, and the node being dialed doesn't bother specifying an endpoint. Thereafter node identity is verified by private key and nodes can fully roam within the firewall-limited subnet. In every case I've seen, roaming by default is the right choice.
- GekkePrutser 4y agoAnother thing I wish it would use is the built in kernel support for wireguard.
- encryptluks2 4y agoWireguard already does this. Did you mean something else?
- GekkePrutser 4y agoYes Wireguard but not tailscale. Tailscale can only use the userspace implementation of Wireguard. Not sure why exactly.
- encryptluks2 4y agoYeah, that would make Tailscale a non-starter for me.
- tptacek 4y agoThese are all reasonable things to want and to track down, but it's worth noting that you in fact don't want WireGuard to support these things out of the box; the point of WireGuard is that it has exactly one job, and that job is integrated as deeply as possible with Linux networking. The things you're asking for are meant to be layered on top of WireGuard.
- candiddevmike 4y agoDon't tell people to not want the most basic amount of security implemented within the protocol. The rest of the Linux kernel networking stack logs more verbosely than WireGuard, and it supports packet filtering. If you had someone compromise your WireGuard mesh, you'd never know. These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff on top of WireGuard creates security footguns. WireGuard's implementation isn't set in stone, it should be improved.