How can I keep my WG Server from changing the Listening Port on Clients

lib · 2021-03-20T10:09:56.471Z

Q: How can I keep my Server from changing the Listening Port

ok… I think i’ve identified my problem, at least in part.

Today, as usual, I woke up to find that I could no longer connect from my laptop wireguard client to my Brume WG Server… I noticed that on the WG SERVER, the “Listening Port” on each of my client configs had changed… but nothing else… so, once logged into the server by hard wire, and noted the change to listening port - i could then change the configs on the client… and viola… it worked again.

It seems strange to me (a noob for sure)… but after I change the listening port on my client solves it and I can now connect… so my basic question is:

Qs:

How can I keep my Server from changing the Listening Port on the client configs?

Is that normal - by design - that the listening port changes?

Why does it change it in the first place? What am i doing wrong?

Thanks for any input!

reflector · 2021-03-21T00:17:24.055Z

actually it shouldn’t matter. when you add a user into your server, all the server needs is a matching address and a key.
the client config part is just a convenient tool to generate all the necessary information to be imported into a device, and there’s no specific port that’s needed on the client side.
try and leave port config blank on the client side, it will randomly use a port to connect the next time rather than locking it into a specific port.

lib · 2021-03-22T06:19:52.273Z

[Interface]

PrivateKey = @$%^&made_up_key_for_informational_purposes@$%^&

1. ListenPort = 8205 (I’m unable to leave this blank)

Address = 10.0.0.2/32

2. DNS = xxx.xxx.xxx.xxx (can I use my own? Google’s? Or just leave it?)

[Peer]

PublicKey = @$%^&made_up_key_for_informational_purposes@$%^&

3. AllowedIPs = 0.0.0.0/0, ::/0 (can I modify this for more protection/restriction?)
4. Endpoint = xxx.xxx.xxx.xxx:51820(not my public IP, but belongs to my ISP… how is this populated?)

PersistentKeepalive = 25

Thank you very kindly for your input… I can’t be the only one who has the following questions… if you would be so kind, can you please help me understand? Above, you’ll find an Apple machine Client config

Questions referencing the numbers above:

On a Mac client config, I’m not allowed to leave the listen port blank… am I understanding your suggestion correctly?

Just out of curiosity… can I use any old DNS? 8.8.8.8? Or should I just leave it as it is? Best practices?

Since we’re discussing… what might this be used for? Can/should it be modified for further privacy - especially if I’m the only one accessing the server… should I just put in my personal range of IP? Again, is there a best practice?

The endpoint IP is not my Public IP… but it does belong to my ISP… I’m unclear on how they got this…
I appreciate your time - thanks for any input you may have…

My original problem still persists… I should mention that this is a secondary router where the WG Server sits (sub net?)… so I guess it’s a double NAT (?)… it must pass through the primary router on my LAN to reach the internet - I have an open port on the primary router to allow the WG Server to be reached remotely.

I know this is a lot to sort through - - - so I very much appreciate your input - best wishes.

funfun · 2021-03-22T08:28:11.155Z

Are you sure you cannot just remove the ListenPort line? It works perfectly under Linux and iOS. It will pick a new one each time. In any case, the server is not really concerned about this.
You can pick anything here… You may want to have your own server here if you run adblock or the like.
This controls what traffic from the client should go through the wireguard tunnel. Your current setting means “all traffic”. But you could change it to have a split tunnel.
I guess the GL-Inet UI uses some sort of external service to “guess” your public IP. This can “fail” in some cases, but it should work if you just have one public IP… are you sure you are not under Carrier-Grade NAT or similar, right?

reflector · 2021-03-22T08:35:17.822Z

i’m using it mainly on mobile. iOS and android app i can leave it blank. every time i connect it will randomise a port. are you able to delete the whole ListenPort line rather than leaving it blank.
yes you can use any dns. you can even use 192.168.8.1(or your router’s local net) to let your own router resolve dns. if you have adguardhome running here you’d get your adblocking + dns over tls/https
Wireguard doesn’t have a “server”/“client” configuration per se, it’s called peers and setting it to 0.0.0.0 sets it to route all through your “server”. site2site would use a different one
i’m not sure how they detect this. but if it’s not your public IP you shouldn’t be able to connect?

lib · 2021-03-22T20:04:49.314Z

YES… thank you… this makes more sense - see my other comments below - but thank you.

lib · 2021-03-22T20:09:44.855Z

Thank you both @Reflector and @FunFun… you are both correct…

Yes, I had to delete the entire line - of course it works on the Mac configs
2.
Great - - I had a feeling I could use any dns… thanks for the explanation
3.
Makes sense
4.
I may be doing something wrong here… but thanks - this makes sense now as well.

lib · 2021-03-23T08:21:03.967Z

@reflector, @funfun

aaarrrgh…
ok - i’m in this a bit over my head… BUT…

This morning, I’m seeing that my connection has again failed… it’s not the listening port (as I’ve deleted this line on my clients)… but I DID notice that the Endpoint IP (my question #4) had changed…

On my own, I configured a DDNS, pointing to my main ISP router (instead of an endpoint IP, I’ve put in my DDNS) and this seems to solve the problem… but I’m just doing this myself… can this be correct?

I haven’t seen anything that says that wireguard needs a static IP… can you guys enlighten me? Am I on the right track?

Thanks in advance!!

alzhao · 2021-03-23T08:48:38.983Z

You should just use your ddns and it works fine.

funfun · 2021-03-23T08:49:10.478Z

Yeah, you may still get issues if your Endpoint IP changes while you have a connected tunnel. Basically, once the tunnel is established, wireguard will never check the DNS name again.

See WireGuard - ArchWiki for how you can workaround the issue.

reflector · 2021-03-23T09:34:08.299Z

i’m not sure how your ISP works, if it changes IP every time you reboot your router, then you’d have to reconnect your WG every time after you reboot.

but if your provider forces an IP change on you every now and then, it’s gonna be troublesome

Johnex · 2021-03-23T10:11:46.337Z

When an ISP wants to force a new IP, all connections will drop so it won’t be an issue. Your client should reconnect automatically because it will do DNS lookup if you set your DDNS address as endpoint. You might have some downtime while the DDNS updates and DNS refreshes though.

funfun · 2021-03-23T10:17:13.988Z

I do not think that’ll be the case with something like wireguard which is connection-less? A new handshake will be tried by wireguard, but on a wrong IP address.

Johnex · 2021-03-23T10:21:37.019Z

Will depend on the client used. Even with UDP when the client does a connection, it will look up the ip pointing to the hostname via a DNS lookup, then try sending packets. So if the client is crap, it might never retry the lookup after XXX failed retries / time. In that case the user should see “oh the connection is down, let me cycle in the app the connection button”.

There are a lot of wireguard client implementations that act differently. I use TunSafe on Windows and it usually can retry even when changing network (wifi to lan etc).

lib · 2021-03-23T10:51:20.701Z

@funfun @alzhao @reflector @Johnex

yes… in fact, I found an old client config… changing the endpoint to the ddns worked right away…
Fingers crossed - that this is the solution - - I’ll report back in a few days… but THANK YOU all for reading/helping - - what a great piece of kit (both hardware and software)…!

funfun · 2021-03-23T11:20:46.789Z

I’m not sure what TunSafe uses, but in my experience with the iOS / Linux official clients, this does not happen. Basically once the tunnel is brought up, it does not try to resolve the Endpoint again.