Closed jberkh closed 5 months ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
Could you explain your use case for this please? Because I'm not entirely sure why you'd need this.
Yes, of course. As example, two persons in a household, who both have always-on VPNs to their home network on their phones, will run into this issue every time they're at home simultaneously
Are you not able to set these clients to not connect when they're on their home network? You'll be causing network performance issues and an additional layer of NAT.
As far as I know, this is not possible automatically. Manual switching would be very bothersome.
Networking isn't my area of expertise, so I'm not sure if/why this would cause performance issues. I'd expect a randomly assigned port to perform equally to a predetermined port, to be honest. Moreover, random client ports is also how other wireguard implementations, like pivpn, generate peer configs: https://github.com/pivpn/pivpn/blob/master/scripts/wireguard/makeCONF.sh (158-188)
Nevertheless, if it indeed does cause performance issues, maybe a fix could be added with an optional env variable, like for instance $NO_PEER_PORT. I think people with similar use cases would rather take the decrease in performance over a largely non-functional configuration
The performance hit isn't due to how the wireguard configs are generated, it's due to you relying on NAT hairpin to route the traffic internally.
Any decent wireguard client can connect dependant on SSID https://github.com/zaneschepke/wgtunnel
That feature is not supported on the official wireguard clients for android, iOS, Windows, and probably also Linux. It is not unreasonable to expect a wireguard server image to work OOTB with these clients.
Regarding performance, can you confirm if I am understanding correctly? It seems to me that removing the ListenPort=51820 from the peer.conf:
You can make any changes you like to the peer or server configs, or indeed to the templates that are used to generate them, to suit your requirements and we won't touch them, but at the moment we have no plans to change the default behaviour of the image. It may be something we consider in the future.
I have this exact setup and it works fine.
When you say When two peers on the same LAN
, does that mean it works fine using mobile data?
The behavior of one phone causing the other to disconnect sounds like you're using the same IP/keys for both.
I see where you're coming from, but I did exclude those options already. Both devices work on the network without wg enabled, and both work from cellular with wg enabled. Also, the issue disappears immediately upon removal of the listenport in the peer configs.
The relevant lines in the NAT table of my router look as follows with the default peer ListenPort=51820 configuration:
Proto NATed Address Destination Address State
udp 192.168.1.100:51820 123.12.123.12:51820 ASSURED
udp 123.12.123.12:1024 192.168.1.2:51820 ASSURED
udp 192.168.1.103:51820 123.12.123.12:51820 UNREPLIED
I see, the ListenPort on peers isn't required in your case, you can remove that line from /config/templates/peer.conf
as Spad suggested.
Is there an existing issue for this?
Current Behavior
When two peers on the same LAN as the server want to connect to the server via its public IP (through NAT loopback), only one is able to do so because the peers use the same port.
Removing the port for the peers allows the wg client to randomly assign a port, thus allowing > 1 connection again.
Expected Behavior
Both peers should be able to connect
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation
Container logs