Client doesn't re-new server domain name on re-try

[vipij]

I have a windows remote client with OpenVPN Connect 3.4.4.
It is automatically started via "ovpnconnector" service at the system boot and tries to connect over the internet to my local openvpn server (on slackware linux, openvpn version 2.5.5).
My server has a dynamic IP, so I set up a domain name by a DDNS service (mydomain.example.net in below example).

Here my client config:

client
dev tun
proto udp
remote mydomain.example.net 12345
ping 10
ping-restart 10
nobind
ecdh-curve secp521r1
remote-cert-tls server
verb 3

If the server is running and its IP is properly resolved using the domain name, the VPN is established and all works fine.

I noticed a problem in the case my server domain name changes.
My server is not always on, I run it when I need to reach remote client. So, the client rests always on and continues trying to connect to server, while this one could be in an on or off state.

• Let's say on the first successful connection "mydomain.example.net" was 1.2.3.4, the client started and resolved the remote name properly, connected and VPN worked OK.
• When I turn off the server, VPN connection goes down.
• The client is again ON ant continue to re-try establishing vpn connection, again and again.
• On server side I turn OFF my router, and turn it on again, so that my ISP assigns an other IP: let's say 5.6.7.8.
• On server side system a ddns service updates the IP of domain name and "mydomain.example.net" points now to 5.6.7.8.
• OK, now I want to connect to remote client.
• So I launch openvpn on the server, and expect the client contacts me at mydomain.example.net (5.6.7.8).
• But something doesn't work.

If I reach the client in some way (I tried using teamviewr for instance), I can read some log of "ovpnconnector.log", and here what is happening:

Wed May 15 13:31:01 2024 EVENT: RECONNECTING
Wed May 15 13:31:01 2024 Contacting 1.2.3.4:12345 via UDP
Wed May 15 13:31:01 2024 EVENT: WAIT
Wed May 15 13:31:01 2024 Connecting to [mydomain.example.net]:12345 (1.2.3.4) via UDP
Wed May 15 13:31:11 2024 Server poll timeout, trying next remote entry...
Wed May 15 13:31:11 2024 EVENT: RECONNECTING
Wed May 15 13:31:11 2024 Contacting 1.2.3.4:12345 via UDP
Wed May 15 13:31:11 2024 EVENT: WAIT
Wed May 15 13:31:11 2024 Connecting to [mydomain.example.net]:12345 (1.2.3.4) via UDP
Wed May 15 13:31:21 2024 Server poll timeout, trying next remote entry...​

The client tries to connect to the old IP assigned to my domain name. Instead it should renew the name resolution by contact system DNS before "EVENT:RECONNECTING".
I noticed there is an "EVENT:RESOLVE" in the log file, but it happens just once when ovpnconnector service is started, at system boot.

This behavior left my client in a "limbo" status of retrying again and again to reach an IP that no longer provides any vpn service.

If I try to launch a "ping mydomain.example.net" from the client, it contacts my actual IP 5.6.7.8. So, at operative system level, windows can resolve properly my domain name with the right new IP address, while ovpnconnector doesn't seem to update it. I suspect it depends on a missing "EVENT: RESOLVE" when it retries to reconnect to the server.

Is there something I can do to solve this issue, for instance by add some option in client config file?
Thanks in advance!

[Pippin]

Hi,

Please take a look at

--ping n
--ping-restart n
--resolv-retry n

in manual 2.6:

https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html

Also read about

keepalive args

[vipij]

In current version 3.4.4 seem some previous options result unsupported/ignored

Wed May 15 13:30:51 2024 Unsupported option (ignored)
Wed May 15 13:30:51 2024 5 [resolv-retry] [infinite]

I had "resolve-retry" but I removed due to that log lines above.
If you look at my above config, "ping " and "ping-restart" options are yet in place but don't do nothing in my case.
If I well understood either ping options and keepalive are intended to control a yet in place vpn tunnel. Instead in my case the issue seems simply related to the client that doesn't renew the remote IP by a simple DNS resolution, even BEFORE establishing the connection to the server.

[Pippin]

Hi,

Indeed, I guess the request would end up in the tunnel... but no complete configuration files were posted.

You could try

--redirect-gateway def1 bypass-dns

^^^ Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel

--dhcp-option DNS dnsserver.reachable.over.tunnel

^^^ For the working tunnel

--block-outside-dns

^^^ Block DNS servers on other network adapters to prevent DNS leaks

If this will work I don't know but worth a try.

[vipij]

The above config I posted is all my client config.
Server config shouldn't influence this issue...

Lets' try with an other example just for testing purpose.
In my above example, server right IP was 5.6.7.8, and the old one 1.2.3.4.

1. try forcing resolution of openvpn server domain name with a static record in local etc/hosts.
In windows by just adding it in the following file:

c:\windows\system32\drivers\etc\hosts

-----------------
1.2.3.4 mydomain.example.net

2. launch the openvpn client service

ovpnconnector start

3. The client begin to contact the wrong IP: it does an "EVENT: RESOLVE", registered in the log

4. It doesn't find the openvpn server (so server config doesn't matter)

5. Waits a bit and retry connect, and so on, again and again.

6. In the meantime time let's try to manually simulate an IP change, by editing hosts file again with the right IP:

c:\windows\system32\drivers\etc\hosts

-----------------
5.6.7.8 mydomain.example.net

7. What the still running "ovpnconnector" service should do now?

[vipij]

Solved by replacing 3.4.4 version with the last stable community version 2.6.10:

client
dev tun
proto udp
remote mydomain.example.net 12345
ping 10
ping-restart 10
nobind
ecdh-curve secp521r1
remote-cert-tls server
verb 3
remap-usr1 SIGHUP

The option "remap-usr1 SIGHUP" seems what solves the issue. Without it I tested same behavior of 3.4.4 version.
With that option if I change IP, it changes IP too and after this re-resolution for the domain name goes on to the next connection retry.

I did a simple test by putting a dummy IP (like 127.0.0.77 for instance) in "hosts" file.
Run the service,
It cannot connect and start retrying again and again.
After that I comment the static entry of mydomain.example.net within hosts file.
Windows then resolves my domain using regular DNS servers likely google or microsoft or something similar, I didn't verify which is configured, anyway my domain IP is now changed.
And OpenVPNService this time really "sense" it, because it re-resolved the domain and tries to establish connection with the new IP.

So it seems to work as expected now. The issue was just related the new commercial version 3.4.4. Maybe there is a way to configure it properly, but as far as I know there's no document which explains well which options are needed to achieve such a result,

Thanks for replies anyway!