The VPN Moved: Why Your OpenVPN Client Still Dials the Old IP

The provider changed your public address, you updated the dynamic DNS record, and the client still cannot connect. From the outside it looks like the record did not propagate. Most of the time the record is fine and the client is dialing the address it resolved before the move, because a running tunnel and a saved profile both have their own idea of where the server lives. Three layers have to agree, and they update on different schedules.

Look at what the profile dials, not what DNS says

Open the connection you are actually using and read the remote line. A numeric address there never follows a hostname update, no matter how correct the record becomes.

Then check whether the profile you edited is the one the client loaded. Imported profiles are common: a manager may have taken a copy months ago and kept its own version, so the file in your downloads directory and the entry in the app can disagree. Compare the endpoint in the client's own connection details before you debug DNS at all.

Two files, one endpoint, is the usual finding here.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Read the client's next connection attempt

Restart the connection with verbose logging and read the line where it names the address it will contact. That value is the one that matters, not what your browser resolved.

A resolver cache can still hold the previous answer, and some networks keep it longer than the record's TTL asks. Query the resolver the client actually uses rather than a public one you tested from elsewhere.

If the log shows the new address and the connection still fails, the problem has moved: the packet is going somewhere and nobody is answering. That is a listener, firewall or port-forwarding question, and it sits on the server side rather than in the client's resolution path. Keep those two failures apart, because treating an unreachable listener as a DNS problem sends you around the same loop twice.

Know which restart you are doing

Not all restarts preserve the same state, which is why an address change can behave differently depending on how the process is recycled. A soft restart triggered by a signal keeps more of the previous session's context, while a full stop and start begins from the configuration again. If you are testing whether the client re-resolves, you want the path that starts from configuration.

Persistence settings also matter, because they are designed to keep what was authenticated rather than to chase new addresses.

The cleanest test is a fresh start from the intended profile, followed by a look at the log line naming the endpoint. Anything you learn from a partially preserved session is a statement about that session.

The four options and their separate jobs

remote with a hostname is the setting that makes re-resolution possible at all; a literal address on that line rules it out. resolv-retry controls what happens when a lookup fails, and 2.6 already defaults it to infinite. Adding it therefore changes nothing, and it never schedules a periodic check for a different answer. Anyone who says it polls for new addresses has confused recovery with freshness.

persist-remote-ip is about continuity rather than freshness: it reuses the endpoint that last authenticated, across the soft restarts it supports. While you are testing a move, that is the opposite of what you want. Disable it for the test if your build enables it, then restore it once the new endpoint is proven. Left on, a successful reconnect may tell you nothing about DNS.

float accepts an authenticated peer whose address changed mid-session, and only in arrangements that support it. It does not refresh DNS, and it will not follow a provider change on its own. Treat it as a resilience feature for peers that roam, not as a dynamic address mechanism for servers.

Confirm the new endpoint before blaming the client

From outside your network, check that the new address has a listener on the configured port and that the provider's forwarding points at it. A correct A record for a machine with no open port produces exactly the symptom people attribute to caching.

Then reconnect and verify two things: the client authenticated against the expected server certificate, and the session reaches the resource you intended. An address change does not lower the identity requirements, and a connection that succeeds to the wrong endpoint is worse than one that fails. The OpenVPN 2.6 manual lists all four options with their own scope, which is the checklist to keep beside the profile.

Keep an out-of-band way into the server before you restart the tunnel that carries your administration access. That single precaution prevents most of the incidents this scenario produces.