Issue with re-resolving dynamic IP when using DynDNS and changing from\to home wifi

alalal

Hello,

I have searched these forums and found 2 posts that describe the same problem but maybe with not enough depth so I hope this clearly explains it and hopefully an option can be developed for these cases.

Setup

Server runs on a private network with all port forwarding and connections working properly.

DynDNS points to the Dynamic IP which then gets forwarded internally.

NAT loopback\hairpin exists so that if a "vpn.dyndns.com" is used it is directed to the WAN IP of the router.

I have my ISP's router which gets a public dynamic IP and my router that I use it's WAN IP as my loopback target (Double NAT)

My router does not face the internet directly and I do not have an option to bridge the connection with my ISP router

From both inside the network or outside the connections work normally.

An Always On VPN client would want to stay connected to the home while roaming out of the house and back.

Where it fails
Example 1:
When outside the home network, the dyndns has resolved my public IP.
When I come home and connect to my wifi OpenVPN tries to reconnect but with my external public IP address that it has resolved vs my WAN IP.
Note: the loopback is to the WAN IP and not to my ISP router's IP as the latter is dynamic so I cannot make it static.
(If i had a static IP I wouldn't need the dyndns and I would have had this as my target IP from the beginning)

Example 2:
When home, it has already resolved the Nat loopback IP (WAN IP) and when i leave the house and it connects on 4G it is still trying to reach that WAN IP.

Basically anyone running it on their home network using a dyndns service and switching between home and data (coming or leaving the house).

Temporary solution
Manually disconnect and reconnect solves this but it has to be done every time and is not seamless.

Solution
I understand this was by design, but a useful option could be to re-resolve the DNS with any (or all) of these options:
1- Change in network detected
2- On reconnect
3- On reconnect after x failed attempts

I hope this was clear enough and detailed. Let me know if more is needed.

Related links I found:
https://forums.openvpn.net/viewtopic.php?f=33&t=24167
https://forums.openvpn.net/viewtopic.php?f=33&t=27375

300000

because your client openvpn routing all over vpn including dns and when it disconect it lost everthing , how can you expect it know dns address when it is disconect state while ip not update yes so the simple one is add this one to your clien config

remap-usr1 SIGHUP
resolv-retry infinite

it will do automatic connect and disconnect for you and you dont need Manually disconnect and reconnect

alalal

300000 wrote remap-usr1 SIGHUP
resolv-retry infinite

Unfortunately this didn't work, but looking at the documentation I found an idea that solved this (so thank you!)

I added an additional remote:
remote 192.168.70.64 PORT
remote DYNDNSADDRESS PORT
remap-usr1 SIGHUP
resolv-retry infinite

Explaining the problem and half the solution
By adding the extra remote address, if my connection starts on data then to wifi then it's able to switch over.
But switching from wifi to data, it would then have the DYNDNSADDRESS resolved to the 70.64 instead of realizing I've left my network and resolving to my public IP (again i'm double NAT'd with no option to create a loopback on my ISP's router, or bridge the connection to my router)

The only good news in this is, as long as I start on data then going to wifi then data, then wifi, then data, etc.... it would be stuck in the WORKING loop since it first started by resolving the DYNDNSADDRESS to my actual public IP and not internally.

Complete solution!
I had a custom setting in my pihole to resolve the (normally unreachable from within) DYNDNSADDRESS to my internal WAN IP (.70.64), making the dyndns and WAN IP each exclusive to the network you would connect from. This solves it by not allowing the dyndns resolved internally to be then cached to the OpenVPN client.
If anyone still needs a working dyndns from within the network then you can just create an additional dyndnsaddress2 that is not used here.