[Bug]: Netmaker is giving wrong port number (public port) to machines on same local network

[lukvacek]

If two clients in Netmaker join the same network, Netmaker correctly sets Wireguard endpoint with their respective local IP addresses, but with the public port number after NAT that the Netmaker server detects outside the local network. This port numbers therefore do not work for the two clients to talk to each other. Both clients are running OS X.

Note that I think initially when the network was setup this worked correctly, but then when one client left the network and rejoined it stopped working.

[Ruakij]

I have noticed the same thing on multiple occasions, very annoying. Even manually setting the port doesnt always work, as the clients sometimes dont pull their settings (or my server is broken?).

[Sitwon]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

[abhishek9686]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

Netmaker uses stun to discover public port, if your device is behind NAT, other devices reach it using the public port which in turn will get mapped to your host listen port after the hole punch that you see on the dashboard

[Sitwon]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

Netmaker uses stun to discover public port, if your device is behind NAT, other devices reach it using the public port which in turn will get mapped to your host listen port after the hole punch that you see on the dashboard

I think you're misunderstanding.

The host on my network has a local IP of 192.168.1.AAA and is listening on port 51823. When I am on the local network, Netclient correctly configures the peer as 192.168.1.AAA:51823.

The firewall on this network is configured to port-forward UDP 51823 to host 192.168.1.AAA. So when I'm not on the local network, the correct address is X.X.X.X:51823 and STUN is not required for this host to be accessible.

However, Netclient instead configures the client as X.X.X.X:53567, which is not the correct port and gets dropped by the firewall.

After I manually correct the peer address, Wireguard connects as it should WITHOUT using STUN.

Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

[yabinma]

By default, using STUN is enabled.
For bypassing STUN, either specify static host when joining a network, netclient join help will print the options Or joining as usual and then setup it as static in the UI(the configuration will be updated automatically).

[Ruakij]

Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

It seems netmaker doesnt really support such (simple) dynamic setups.. for years now. maybe better to switch to netbird instead. Much less problems since i switched.

[abhishek9686]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

Netmaker uses stun to discover public port, if your device is behind NAT, other devices reach it using the public port which in turn will get mapped to your host listen port after the hole punch that you see on the dashboard

I think you're misunderstanding.

The host on my network has a local IP of 192.168.1.AAA and is listening on port 51823. When I am on the local network, Netclient correctly configures the peer as 192.168.1.AAA:51823.

The firewall on this network is configured to port-forward UDP 51823 to host 192.168.1.AAA. So when I'm not on the local network, the correct address is X.X.X.X:51823 and STUN is not required for this host to be accessible.

However, Netclient instead configures the client as X.X.X.X:53567, which is not the correct port and gets dropped by the firewall.

After I manually correct the peer address, Wireguard connects as it should WITHOUT using STUN.

Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

@Sitwon set the host as static from the host settings and run netclient pull on that machine that should solve your issue. You can also set the host as static while joining the network as well by passing arg -i true to netclient join command

[abhishek9686]

Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

It seems netmaker doesnt really support such (simple) dynamic setups.. for years now. maybe better to switch to netbird instead. Much less problems since i switched.

@Ruakij can I know what's lacking in netmaker that couldn't support your use case?

[Sitwon]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

Netmaker uses stun to discover public port, if your device is behind NAT, other devices reach it using the public port which in turn will get mapped to your host listen port after the hole punch that you see on the dashboard

I think you're misunderstanding. The host on my network has a local IP of 192.168.1.AAA and is listening on port 51823. When I am on the local network, Netclient correctly configures the peer as 192.168.1.AAA:51823. The firewall on this network is configured to port-forward UDP 51823 to host 192.168.1.AAA. So when I'm not on the local network, the correct address is X.X.X.X:51823 and STUN is not required for this host to be accessible. However, Netclient instead configures the client as X.X.X.X:53567, which is not the correct port and gets dropped by the firewall. After I manually correct the peer address, Wireguard connects as it should WITHOUT using STUN. Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

@Sitwon set the host as static from the host settings and run netclient pull on that machine that should solve your issue. You can also set the host as static while joining the network as well by passing arg -i true to netclient join command

But it's NOT a static endpoint, because the public IP address for this network is not static. So I guess I either need to use DynDNS or manually update the host in the Netmaker Dashboard each time the IP changes? Or will it still pick up the IP changes even with the host marked as static?

It seems to me that NM should be able to verify that the configured listen port is open and skip utilizing STUN.

[abhishek9686]

I have also been hit with this problem. The host is configured to use port 51823, and that's how I configured the port forwarding rule in my firewall. When I'm on the same local network it works fine, but when I'm on a different network Netmaker gets the external IP address right, but gets the port number wrong. The correct port number is shown as the Listen Port for the host in the NM Dashboard. But for some reason netclient still configures the wrong port, forcing me to manually correct the port number every time (which negates the whole purpose of using Netmaker to begin with.)

Netmaker uses stun to discover public port, if your device is behind NAT, other devices reach it using the public port which in turn will get mapped to your host listen port after the hole punch that you see on the dashboard

I think you're misunderstanding. The host on my network has a local IP of 192.168.1.AAA and is listening on port 51823. When I am on the local network, Netclient correctly configures the peer as 192.168.1.AAA:51823. The firewall on this network is configured to port-forward UDP 51823 to host 192.168.1.AAA. So when I'm not on the local network, the correct address is X.X.X.X:51823 and STUN is not required for this host to be accessible. However, Netclient instead configures the client as X.X.X.X:53567, which is not the correct port and gets dropped by the firewall. After I manually correct the peer address, Wireguard connects as it should WITHOUT using STUN. Within the Netmaker Dashboard, I can see that Netmaker has the correct Listen Port for the peer, so I have no idea why it would attempt to use STUN at all (and fail at it), rather than use the Listen Port that is correctly port-forwarded.

@Sitwon set the host as static from the host settings and run netclient pull on that machine that should solve your issue. You can also set the host as static while joining the network as well by passing arg -i true to netclient join command

But it's NOT a static endpoint, because the public IP address for this network is not static. So I guess I either need to use DynDNS or manually update the host in the Netmaker Dashboard each time the IP changes? Or will it still pick up the IP changes even with the host marked as static?

It seems to me that NM should be able to verify that the configured listen port is open and skip utilizing STUN.

When the Host is static, both IP and port don't change, but looking at this I will raise a concern with the team to separate out static functionality for port and IP to be independent for now, you can set the host to be static, and change the IP manually