September 8th, 2024

I wish (Linux) WireGuard had a simple way to restrict peer public IPs

Chris Siebenmann highlights WireGuard's limitations in restricting peer public IP addresses, suggesting the need for multiple ports or interfaces for security, and proposes potential kernel-level extensions for better peer management.

Read original articleLink Icon
I wish (Linux) WireGuard had a simple way to restrict peer public IPs

Chris Siebenmann discusses the limitations of WireGuard, a tool for creating encrypted connections, particularly regarding the restriction of peer public IP addresses. Unlike SSH, which allows for IP restrictions through the 'from="..."' option in the authorized keys, WireGuard does not provide a straightforward method to enforce such restrictions. While it is possible to set an expected public IP for a peer, WireGuard will update its records if the peer connects from a different IP, which can be problematic for secure connections that require fixed IPs. The author notes that while firewall rules can be used to restrict access to the WireGuard port, they have limitations, such as not being able to differentiate between multiple peers using the same key. This could lead to security vulnerabilities. To effectively manage multiple peers, different listening ports or separate WireGuard interfaces are necessary, complicating the setup. Siebenmann also speculates on the potential for developing an extension for nftables or iptables that could integrate with WireGuard to better manage peer identities, possibly using eBPF programs.

- WireGuard lacks a simple method to restrict peer public IPs, unlike SSH.

- Firewall rules can restrict access but do not differentiate between peers effectively.

- Multiple listening ports or separate interfaces are needed for managing multiple peers securely.

- The author suggests potential development of kernel-level extensions for better peer management.

- The discussion highlights the need for improved security features in WireGuard implementations.

Link Icon 5 comments
By @ta1243 - 7 months
"any peer public IP can impersonate any other (if it has the required WireGuard peer key"

Right. So you want to put in IP filtering on top of that, having already had a compromised connection?

The biggest issue I have with wireguard is the tendancy for clients to actually show the private key. It shouldn't generally be visible, there's no needs.

By @tracker1 - 7 months
So, install and use ufw or another simple filtering tool or iptables directly.

I'm no expert in Wireguard other than setting it up for personal use at home, so don't quite know more advanced configurations, but this seems like a separate issue relatively easily handled. That said, for my own use case, I wouldn't want to restrict IPs beyond maybe nation restrictions as I expect to connect from untrusted locations.

By @ralferoo - 7 months
I'm slightly confused. What the author seems to be saying (although he doesn't state it quite so directly) is that even if you specify "Endpoint = ip:port" in the configuration, that Wireguard will update that if it receives a correctly authenticated packet from a different IP address.

At first, I thought this sounded like a bug, but actually reading the documentation [1] it's clearly as-designed. It's referred to as "initial configuration" (their italics) and then explains how it updates.

I see there's an official mailing list for wireguard. Perhaps he should suggest a new feature there to disable that roaming functionality.

[1] https://www.wireguard.com/ in the "Built-in Roaming" section

By @rudasn - 7 months
Anyone else having the issue of how to distinguish traffic from specific peers, and how did you solve it?

Other than having an interface per peer of course.