lib
1
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!
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
3
[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.
lib
6
YES… thank you… this makes more sense - see my other comments below - but thank you.
lib
7
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
8
@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
9
You should just use your ddns and it works fine.
1 Like
funfun
10
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.
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
12
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.
1 Like
funfun
13
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
14
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
15
@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
16
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.