https://netmaker.org logo
Powered by
All clients lose connectivity when UDP hole punchi...
# server
f
All clients lose connectivity when UDP hole punching enabled
Hello, if this has been asked before please point me in the right direction. I've setup a test environment with 8 clients between two locations, server runs on on a cloud instance. For some reason if i enable UDP hole punching ALL clients lose connectivity, if i switch UDP hole punching back off, they all start functioning again. Because UDP hole punching is not enabled currently i did create some port forwards for the clients behind NAT. I cannot for the life of me figure it out, i have tried changing outbound DNAT to not randomize the outbound ports for testing purposes but it did not seem to help. Thanks! - Client and server versions are 0.14.5
b
perhaps a firewall issue on server... Does server permit incoming UDP on ports 51821-51830?
f
Yes, and those ports work perfectly without UDP hole punching enabled
Just to be sure ill disable the firewall entirely, i have not done that yet to be honest.
b
can you check to see if any of the nodes actually establish a handshakes
f
looking at the Wireguard log?
b
just do a wg show and look at the Rx Tx bytes
f
one sec just firing up some pings on both sites and ill check
This must be the firewall interfering somehow agh, if i set the clients to relay through the netmaker instance it works, without the relay even clients on the same subnet do not work unless UDP hole punch is disabled.
i'm using Watchguard on one site and pfsense on another if it matters.
b
if you disable the firewall then it works????
f
disabled firewall on the cloud netmaker instance and the clients, the only thing that remains is my the NAT/Firewall for my access to the internet.
Here is a screenshot from my windows server on site 1, on the same network is a web server and a file server, this is with UDP hole punching disabled.
Enabled -
all clients have firewall disabled
b
but does it work with upd holepunching on and firewall disabled
f
No, the ONLY way i can get client connectivity is if i relay them all with the netmaker instanace (Which is in the cloud) when UDP hole punching is enabled.
b
with upd hole punching on, is a wireguard handshake established
f
No, no successful handshake
b
firewall somewhere
f
i'm comparing configurations on both clients that netmaker generates
this must be an issue with how the netmaker instance is populating the port, the one client is listening on port 51823, but the other client is trying to connect on port 52570
i forget the term, port masquerading? for UDP outbound, i wonder if thats the cause
b
upd hole punching works as follows....
server node istens on defautl port. node uses random port and handshakes with server node. server node notes the port the peer used to connect and then sends a peer update to all other nodes
f
yeah, crap.
by default both firewalls i'm using include "Source port randomization" infact i think any of the major players will, Sonicwall, etc
going to see if i can override this rule to test
Worked 😐
Not ideal, but its a solution, as a test i set outbound nat to static for all.
i wonder if there is a more elegant solution, source port randomization is very very common for any NAT device.
b
but if you send an upd packet out then some one else should be able to connect to the port the firewall set as long as the connection has not timed out
f
ill have to look into it more, it looks like netmaker was recording the incorrect port and handing it to the client, client was trying to connect to an invalid port.
What would cause this?
ListenPort = 0
b
turning udp hole punching on
f
OK, expected? ill try to dig more into it more later, i'm able to get through these firewalls with other products using hole punching.
b
yes... when listenport = 0 or not present, wireguard will use a random port
f
Thanks for your time.
8 Views
PreviousNext
Powered by