VPN-Servers: Unreliable client configurations

Even though I enabled DDNS on my Beryl both, the WG-server as well as OVPN-server, create client configs that use todays public IP of my Beryl.
Huge parts of todays ISP customers do have dynamic IPs (you know it - it’s the reason you implemented DDNS in the 1st place :wink:) - for those the VPN will only work until the public IP of the VPN server changes (over here: only 1 day :scream:).

So please change the way you create the corresponding entries in the client configs from [todays pubIP] to [DDNS-name],

e.g. for Wireguard
from
[Peer]
Endpoint = 21.22.23.24:51820
to
[Peer]
Endpoint = asdfg27.glddns.com:51820

for OpenVPN
from
remote 21.22.23.24 1194
to
remote asdfg27.glddns.com 1194

Thank you.

I’d go a step farther and in case DDNS is not enabled even suggested to enable DDNS when creating an new VPN server.
As you mainly deal with plain customers it was even better to make DDNS mandatory - when a VPN server is enabled DDNS gets automatically enabled, the DDNS name is used in the client configs. Just pls tell the customer about it in the UI (e.g. “When enabling a VPN server DDNS gets enabled automatically”).

I don’t mind a recommendation for DDNS, but please don’t turn on DDNS automatically, as some of us have configurations that we only want to use IP addresses, or we want to use our own version of DDNS code which may not be running on the router.

2 Likes

Those ppl are geeks and should know how to manually edit openVPN/WG configs. They have to put in their individual DDNS names anyway - otherwise VPN won’t work after next IP change.

Actually I see only 1 single downside to my suggestion in Post 2: Privacy. glddns.com knows the devices public IP.¹
Ppl that mind such should never use routers not running plain OSS like openWRT.

In general:
The standard behavior of end-user devices should cover the broad customer base (“DAU”), not the geeks. These non-geeks/noobs have to be able to easily configure router functions. No knowledge about networking etc. required.
That’s why it was IMO essential to enable DDNS when enabling VPN servers and use its name in the VPN configs.

¹ in case you see other reasons pls. tell, I’m eager to learn new perspectives

Thank you for the compliment of being called a geek. Anyone setting up a server on the Internet should be a bit of a geek, as you are opening ports and incurring risks of attacks on your internal network. In many cases, you are also modifying forwarding/firewall rules on your home/office router, which you should not be doing without a bit of knowledge. I have seen people turn off all firewall rules to get a home server to work, which is just plain dangerous

Automatically sending information out of the router, to any site, including to glddns.com should always be a user selected option. I have the same issue with GL iNet running mwan3 as the default, as it pings Google servers without informing you, or having an easy way to turn this off in the GL iNet GUI.

Lastly, just as a FYI, not all GL iNet routers are able to run the current version of OpenWRT firmware.

See?
That’s one reason why it’s good a customer device has some default settings that ‘just work’ - built by ppl who know what/why they do. The price of unnecessarily exposing the own IP to glddns.com is IMO tiny for that.

:grinning: guess China-routers aren’t for you then.
I agree, but if one chooses a China-router one should expect some data leakage. In this special case (DDNS) I think that the advantages way outweigh the downsides.

Yeah, traced that unwanted-ping-to-Google down to mwan3 as well. Even though (F)OSS this packet still is leaking data.
You can change the IP addresses pinged in /etc/config/mwan3 though.

IKR! But its pretty simple: Privacy aware ppl cannot buy them :man_shrugging:
Privacy and data integrity ain’t a cheap business but expensive and time-consuming. Anyone has to decide his own threat-level and act accordingly.
What I simply do not accept is to buy a China-router and then complain. Those should get a Mikrotik router or (way easier!) use a RasPi /w e.g. IPFire.