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 articleChris 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.
Related
Evolving the BSD Cafe Network Setup: From Bridging to Routing with FreeBSD
The article outlines the evolution of a FreeBSD network setup from a simple VPS to a complex multi-node network, emphasizing improved security, performance, and adaptability through advanced configurations and routing techniques.
Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard
Jamil Bou Kheir's Firezone is a remote access platform using WireGuard to enhance security for remote work, simplifying access control and deployment while addressing traditional VPN limitations.
WireGuard-rs – Official Rust implementation of WireGuard
wireguard-rs is a Rust implementation of the WireGuard VPN protocol, featuring updates for performance, sticky sockets for Linux, and ongoing maintenance, with the code available under the MIT license.
Wush: Simplest and fastest way to transfer files between computers via WireGuard
Wush is a command line tool for secure file transfers and shell access using WireGuard, eliminating the need for relay servers, enhancing security, and supporting various tasks like SSH and file transfers.
Making the Easy Things Easy with WireGuard
DevZero enhances developer tooling by using WireGuard for secure connections, simplifying remote access, reducing latency, and improving performance while emphasizing a commitment to open-source technologies.
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.
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.
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
Other than having an interface per peer of course.
Related
Evolving the BSD Cafe Network Setup: From Bridging to Routing with FreeBSD
The article outlines the evolution of a FreeBSD network setup from a simple VPS to a complex multi-node network, emphasizing improved security, performance, and adaptability through advanced configurations and routing techniques.
Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard
Jamil Bou Kheir's Firezone is a remote access platform using WireGuard to enhance security for remote work, simplifying access control and deployment while addressing traditional VPN limitations.
WireGuard-rs – Official Rust implementation of WireGuard
wireguard-rs is a Rust implementation of the WireGuard VPN protocol, featuring updates for performance, sticky sockets for Linux, and ongoing maintenance, with the code available under the MIT license.
Wush: Simplest and fastest way to transfer files between computers via WireGuard
Wush is a command line tool for secure file transfers and shell access using WireGuard, eliminating the need for relay servers, enhancing security, and supporting various tasks like SSH and file transfers.
Making the Easy Things Easy with WireGuard
DevZero enhances developer tooling by using WireGuard for secure connections, simplifying remote access, reducing latency, and improving performance while emphasizing a commitment to open-source technologies.