Has anyone tried using netclient with multiple Wan routers? I am not sure whether it is caused by symmetric NAT or multiple Wan routers, because I encounter a network environment, that is, symmetric NAT, and multiple public IP, and the public IP is constantly changing randomly. I guess it is because of this reason. I don't understand the workflow of netclient and the impact of changing public IP on it.

netclient checks periodically (every minute) to see if its public ip has changed. If it has, it sends a message to the server which will in turn send a message to all the peers of the node informing them of the new endpoint for the node.

Whether the detected public ip: port is inconsistent with the ip: port used by WG. For example, when detecting the ip: port, it may go out through another line. This is a question.

Change the endpoint to static in the ui and select an ip

The symmetric router at the upper end is controlled by the operator, and we have no right to change it. The IP is dynamically and randomly changing and set to static. I don't think it can be solved well.

Is the client on the router or behind the router?

Detecting the ip: port of WG should be completed from the server, not the client, so as to maintain consistency.

we used to detect ip from the server but this caused issues, because sometimes the docker/k8s routing gets in the way, and netmaker sees the bridge interface instead of the public ip

The client is behind the router

can you confirm this?

I will test this as soon as possible,

you don't have to do anything client-side, you do it from the UI.

I understand. I will try to get the test again

I'm not sure how we'd be able to do both. Either the endpoint is detected dynamically and it can change, or you tell it to keep the IP

This is why I mentioned WG SD repeatedly. Its working principle can give us inspiration

I agree with this in principle, we looked into integrating wgsd for a while, but not sure if we're willing to do such a big refactor of hole punching at the moment

Maybe we have a better method than wg-sd to report to the server. The current WG accurate ip:port

This would be ideal and is how it used to work. However, we found a pretty bad flaw with this design. Typically, the WG interface on the server will have the correct ip:port on initial startup. However, if anything wipes the interface (restart, change to server node), then the ip of ip:port becomes inaccurate. Let's say you have 1 client on the server at 1.2.3.4. When it first checks in with server, it will show in peers list as: endpoint: 1.2.3.4:12345 then, something happens to server such as a docker restart. When it comes back up, we see the peer changes to this: endpoint: 172.168.1.25:12345 where 172.168.1.25 is the docker gateway address. Then, this IP gets sent out to the clients, and the become unreachable.

I hope this problem can be solved as soon as possible. It is very important to drill holes in the underlying UDP. Relaying is not a good way

I have a somewhat similar setup. My provider gives me different IPs based on the destination. So in the code you have a few endpoints to get public ip (like ifconfig.me, etc) and they return different values. It doesn't impact me much so far as most my nodes have static public IPs, but it would be great to see a solution, sure

We'll need to have a broader discussion on this since it would be a big change. It's doable, but will have consequences. I'm open to suggestions if we want to cntinue this in the architecture channel