[BUG] ListenPort = 51820 in default peer.conf disallows >1 peer through NAT loopback about docker-wireguard HOT 11 CLOSED

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

from docker-wireguard.

Could you explain your use case for this please? Because I'm not entirely sure why you'd need this.

from docker-wireguard.

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

from docker-wireguard.

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.

from docker-wireguard.

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

from docker-wireguard.

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

from docker-wireguard.

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:

• would not negatively affect anyone not using NAT hairpin
• would only decrease performance compared to the hypothetical situation of not using wg on the home network
• would actually increase performance compared to the current non-functional state of using wg on the home network with NAT hairpinning

from docker-wireguard.

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.

from docker-wireguard.

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.

from docker-wireguard.

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

from docker-wireguard.

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.

from docker-wireguard.