The loss of internet connection does not kill OpenVPN client connection, and the OpenVPN client does not reconnect when internet connection has been reestablished.
A reboot is for now neccessary to reconnect OpenVPN tunnel.
This issue is seen on RUT241 with Firmware: RUT2M_R_00.07.15.1 and modem firmware: SLM750-V_4.57.20_EQ101
Is there Any way to monitor a VPN tunnel ip address and if lost connection, then kill the specific VPN client/tunnel and hereafter reconnect VPN client/tunnel?
A workaround can be to use the Auto Reboot/Ping/WGet Reboot. But this makes router disconnected the internet for some minutes minutes before up and running again.
A solution based on internet connection failover or loss (Kill VPN tunnels) and when regain internet connection (Restablish VPN tunnels). This could a check mark where Failover is configured.
Hop to hear if a solution exists, or if a solution could be included in the next firmware release?
I’ve attempted to reproduce the issue that you’ve explained by imitating a loss of internet connectivity while being connected to an OpenVPN server; however, I was unable to obtain the same results you did, as my connection came back in about 30 seconds to a minute or so.
I’d assume your device acts as a client in this scenario. What is the server that you’re connecting to? Are you able to view active sessions / connected clients in the server logs/dashboard? If so, if you were to imitate a loss of connectivity and then reconnect to the internet, although the WebUI might say “Disconnected”, does your device appear in the client list? Are you able to ping any end devices or such?
We had the issue several times. The RUT241 act as OpenVPN client towards a OpenVPN Server on a pfsense 2.7.2. On the OpenVPN server the connection is dissapeared.
We also have MileSight UR32S and TP-link ER605 which all reestablish the OpenVPN connection after loss of internet connection.
We have no indication from our other VPN connections that the VPN Server has issues.
Here follows 6 lines from the log, where the a break of internet connection happens, and internet reappear after 38 seconds. After this OpenVPN client tunnel is lost.
|ID|Date|Source|Event group|Event type|Event|
|288|2025-06-30 04:34:08|Network Type|Network|Info|Joined LTE network (internal modem)|
|287|2025-06-30 04:34:08|Mobile Data|Network|Info|Mobile data connected (internal modem)|
|286|2025-06-30 04:33:58|Failover|Network|Info|Switched to backup WAN (mob1s1a1)|
|285|2025-06-30 04:33:45|Failover|Network|Info|Switched to backup WAN (mob1s1a1)|
|284|2025-06-30 04:33:30|Mobile Data|Network|Info|Mobile data disconnected (internal modem)|
|283|2025-06-30 04:33:23|Failover|Network|Info|WAN (mob1s1a1) is down, no more backups to switch|
The openVPN client log is not cumulative and does only have log information since the start of the OpenVPN client.
The RUT41 is at a remote site. When the internet connection is lost i have no VPN connection and i must reboot the device with a SMS command to have remote access through OpenVPN to the RUT241.
After the reboot the OpenVPN log containing information up to the reboot is lost.
If the old log files is available, i cannot find them. On my window OpenVPN client the log file is over written at start of the OpenVPN client.
I have added the “log-append” to the OpenVPN client config. At the next loss of internet connection, the OpenVPN log should not be overwritten after reboot. It might take some days days before this happen, and i will update this thread.
The was a loss of internet earlier this day. The OpenVPN client version could not take oprtion “log-append”, and this did break OpenVPN to start after boot. And the logfile was overwritten.
Any sugestion how to allow the OpenVPN client add to the log file, instead of overwriting when starting a OpenVPN tunnel?
Let’s do this instead - since OpenVPN is a part of the service list for the device, it’ll get saved within the Troubleshoot file logs. I’ve sent you a form to fill out so we can continue our conversation in private, to avoid accidentally leaking any sensitive information. In the Ticket ID field, simply enter the thread’s number, which is 14454.
