I have enabled the Inbound Firewall on Tun and also checked the Killswitch in the GUI. I assume this only applies to my PBR so other devices are not impacted during a drop.
Update : Although enabling the Killswitch did solve the VPN reconnect with PBR, it's still not working as I'd expect. Post Inactivity Timeout and reconnect my log file is no longer being populated. So after some duration (day or two) the connection dropped, killswitch kicked in but since there's no log updates I can't see what's going on. I did reboot after enabling the killswitch per the setup guide.
Connection Problems
When the tunnel goes down and does not reconnect because it cannot resolve the url address of the server and cannot set a route to the new server, this can be due to the route-up and down script are not being reread (because of the persist-tun parameter).
This will keep the resolv.dnsmasq with pushed DNS servers which are not publicly available and keep the pre-existent routes.
So the tunnel should be restarted, you can force a restart with adding in the additional config:
remap-usr1 SIGHUP
Other things which might help:
keepalive 10 120 #check if provider does not pushes ping-exit, that takes precedence and you have to use a watchdog
resolv-retry infinite
You can also try adding the server's domain name as a route directive to force *all* its public IPs to be bound to the WAN, add in the additional config (this can be useful if you have the error: RESOLVE: Cannot resolve host address ….):
route <server url> 255.255.255.255 net_gateway
In the end you might need a tunnel watchdog see third post of this thread or simply use the built-in connection watchdog to reboot the router if a connection is lost.
What bugs me about this is what's listed as purpose of the script "(re)start failed/stopped/unresponsive openvpn client". My connection status shows CONNECTED SUCCESSFUL again, IP tables look fine. The client itself appears to be fine but Killswitch kicks in for PBR devices. I'm adding in remap-usr1 SIGHUP to config to see if that helps before looking at the watchdog script.
What bugs me about this is what's listed as purpose of the script "(re)start failed/stopped/unresponsive openvpn client". My connection status shows CONNECTED SUCCESSFUL again, IP tables look fine. The client itself appears to be fine but Killswitch kicks in for PBR devices. I'm adding in remap-usr1 SIGHUP to config to see if that helps before looking at the watchdog script.
One of the unfortunate aspects of OpenVPN as implemented by *some* providers, esp. the cheaper, less reputable ones, is that they will sometimes force an AUTH FAIL condition to manage their servers. IOW, even though the username/password provided is perfectly valid, they'll restrict access to the server through this method (perhaps for reasons of maintenance, overloading, etc.). The problem from the perspective of the OpenVPN client is that this is considered a FATAL ERROR! It will KILL the OpenVPN client process, trigger the kill switch (if enabled), and produce no further output in the syslog.
IMO, this is the number one reason the watchdog script is necessary. VPN providers are essentially "breaking the rules" for their own reasons. And the only way to combat it is to detect if and when the OpenVPN process gets killed off in this manner and force a restart.
Even if you include multiple servers (in the form of additional remote directives in the Additional Config field), it won't help. It's assumed that any incorrect username/password will fail for ANY and ALL servers you have specified in the config.