[BUG] ListenPort = 51820 in default peer.conf disallows >1 peer through NAT loopback #334
Comments
|
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. |
|
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: |
|
I see, the ListenPort on peers isn't required in your case, you can remove that line from |
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
vpn: image: linuxserver/wireguard container_name: vpn depends_on: - pihole cap_add: - NET_ADMIN - SYS_MODULE environment: - PUID=1000 - PGID=1000 - LOG_CONFS=true - SERVERURL=vpn.domain.com - SERVERPORT=51820 - INTERNAL_SUBNET=10.6.0.0 - ALLOWEDIPS=0.0.0.0/0 - PEERDNS=${PIHOLE_IP} - PEERS=peer1,peer2,peer3 sysctls: - net.ipv4.conf.all.src_valid_mark=1 networks: dns: ipv4_address: ${VPN_IP} dns: - ${PIHOLE_IP} ports: - ${SERVER_IP}:51820:51820/udp volumes: - ${NETWORKING}/vpn:/config - /lib/modules:/lib/modules restart: unless-stoppedContainer logs
The text was updated successfully, but these errors were encountered: