OpenVPN on RouterOS 5.2 restarts every hour

Hello,

I decided to try RouterOS 5.2 on one of my rg450g routers.
Also, I decided to test the OpenVPN since I use it a lot.
The OpenVPN client is version 2.1.4 running on CentOS and is compiled with OpenSSL 1.0.0d.
The problem is that the OpenVPN client is restarted every hour sharp with connection reset.

This is the configuration of my OpenVPN server:

/ppp profile
set default change-tcp-mss=yes name=default only-one=default use-compression=default use-encryption=default use-mpls=default use-vj-compression=default
add bridge=intranet change-tcp-mss=default local-address=192.168.1.1 name=openvpn only-one=default remote-address=openvpn use-compression=default
use-encryption=required use-mpls=default use-vj-compression=default
set default-encryption change-tcp-mss=yes name=default-encryption only-one=default use-compression=default use-encryption=yes use-mpls=default
use-vj-compression=default
/ppp aaa
set accounting=yes interim-update=0s use-radius=no
/ppp secret
add caller-id=“” disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=192.168.1.1 name=User1 password=
“password123” profile=openvpn remote-address=192.168.1.2 service=ovpn


This configuration was imported from RouterOS 4.17 which is running on another router of mine.
I don’t have any issue with the same configuration on 4.17.

Also, I have started ping 192.168.1.1 in order to constantly generate traffic over the tunnel.
I have “keepalive 10 120” on the client side in order to check the tunnel and restart it in case of problem.
I don’t know whether it is possible to increase the level of logging for OpenVPN on my router, but this how my logging is set currently:

/system logging action
set memory memory-lines=100 memory-stop-on-full=no name=memory target=memory
set disk disk-file-count=2 disk-file-name=log disk-lines-per-file=100 disk-stop-on-full=no name=disk target=disk
set echo name=echo remember=yes target=echo
set remote bsd-syslog=no name=remote remote=0.0.0.0 remote-port=514 src-address=0.0.0.0 syslog-facility=daemon syslog-severity=auto target=remote
/system logging
add action=memory disabled=yes prefix=“” topics=info
add action=memory disabled=yes prefix=“” topics=error
add action=memory disabled=yes prefix=“” topics=warning
add action=echo disabled=yes prefix=“” topics=critical
add action=memory disabled=yes prefix=“” topics=debug
add action=memory disabled=no prefix=“” topics=ovpn

The only information what I can see is when the client has been disconnected and reconnected.
The interval between reconnects is 1 hour sharp.

FWIW, we have been seeing the same thing since we upgraded our x86 edge router to 4.17 (was running 4.11 previously). We have an OpenVPN server running behind the router via dst-nat. Since the upgrade, every 60 minutes–often down to the second–all of our VPN clients lose the connection simultaneously, and often take several minutes to reestablish.

If you do find out the cause and/or a workaround, please follow-up to this thread.

we fixed an openvpn problem in v5.3, you can email support to get a pre-release

I already tested pre-release 5.3 and based on my testing there are still 3 open issues in OVPN:

  1. ROS [OVPN client] → Linux [OVPN server]
  • after 1 hour OVPN disconnected, in log there is a message: “bad data has received”
  • authentification via certificates
  1. Windows XP [OVPN client] → ROS [OVPN server]
  • client is disconnected after 1 hour, need to re-authentificate
  • authentification via username/password
  1. RB750 [OVPN client] → RB433AH [OVPN server]
  • 100% CPU on OVPN client


    Do you have any of listed issues, too, please?

Issues (1) and (3) are on ROS 5.1/5.2, on ROS 4.17 everything is working correctly. Issue (2) is actual on versions 3.x/4.x/5.x . All these issues are under investigation of support, ticket 2011042866000672.

I got update from Mikrotik support team, that the issue with “bad data received” should be fixed, it will be released in next versions.

I’m putting update here for keeping interested people updated :slight_smile:

“Bad data received” issue is fixed in final 5.3 .