3 ms·
> 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
by 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.