Lost connection (OpenVPN)?

Question

openvpn

The connection periodically disappears, usually for a few seconds then it is restored, before that everything was ok - a stable connection.
The following errors began to appear in the logs:

Sun May 12 10:52:58 2019 interactive service msg_channel=660
Sun May 12 10:52:58 2019 ROUTE_GATEWAY 10.27.128.69/255.255.255.252 I=15 HWADDR=macadress
Sun May 12 10:52:58 2019 open_tun
Sun May 12 10:52:58 2019 TAP-WIN32 device [Ethernet] opened: \\.\Global\{7CA6DCF4-4AE0-4FFE-85AF-C902629814FC}.tap
Sun May 12 10:52:58 2019 TAP-Windows Driver Version 9.23 
Sun May 12 10:52:58 2019 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.3/255.255.255.0 [SUCCEEDED]
Sun May 12 10:52:58 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.3/255.255.255.0 on interface {7CA6DCF4-4AE0-4FFE-85AF-C902629814FC} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Sun May 12 10:52:58 2019 Successful ARP Flush on interface [10] {7CA6DCF4-4AE0-4FFE-85AF-C902629814FC}
Sun May 12 10:52:58 2019 MANAGEMENT: >STATE:1557625978,ASSIGN_IP,,10.8.0.3,,,,
Sun May 12 10:52:58 2019 Blocking outside dns using service succeeded.
Sun May 12 10:53:03 2019 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Sun May 12 10:53:03 2019 C:\WINDOWS\system32\route.exe ADD ipadresservera MASK 255.255.255.255 10.27.128.69
Sun May 12 10:53:03 2019 ROUTE: route addition failed using service: Ýòîò îáúåêò óæå ñóùåñòâóåò.   [status=5010 if_index=15]
Sun May 12 10:53:03 2019 Route addition via service failed
Sun May 12 10:53:03 2019 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Sun May 12 10:53:03 2019 Route addition via service succeeded
Sun May 12 10:53:03 2019 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Sun May 12 10:53:03 2019 Route addition via service succeeded
Sun May 12 10:53:03 2019 Initialization Sequence Completed
Sun May 12 10:53:03 2019 MANAGEMENT: >STATE:1557625983,CONNECTED,SUCCESS,10.8.0.3,ipadresservera,1194,,
Sun May 12 10:56:46 2019 AEAD Decrypt error: bad packet ID (may be a replay): [ #6590 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun May 12 10:57:46 2019 AEAD Decrypt error: bad packet ID (may be a replay): [ #10089 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun May 12 11:52:57 2019 VERIFY OK: depth=1, CN=cn
Sun May 12 11:52:57 2019 VERIFY KU OK
Sun May 12 11:52:57 2019 Validating certificate extended key usage
Sun May 12 11:52:57 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 12 11:52:57 2019 VERIFY EKU OK
Sun May 12 11:52:57 2019 VERIFY X509NAME OK: CN=server
Sun May 12 11:52:57 2019 VERIFY OK: depth=0, CN=server
Sun May 12 11:52:58 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May 12 11:52:58 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun May 12 11:52:58 2019 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES128-GCM-SHA256, 3072 bit RSA
Sun May 12 12:52:56 2019 TLS: tls_process: killed expiring key
Sun May 12 12:52:58 2019 VERIFY OK: depth=1, CN=cn
Sun May 12 12:52:58 2019 VERIFY KU OK
Sun May 12 12:52:58 2019 Validating certificate extended key usage
Sun May 12 12:52:58 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May 12 12:52:58 2019 VERIFY EKU OK
Sun May 12 12:52:58 2019 VERIFY X509NAME OK: CN=server
Sun May 12 12:52:58 2019 VERIFY OK: depth=0, CN=server
Sun May 12 12:52:59 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Answer 1

The first error is an incorrectly set route option in the config, most likely or an attempt to re-register the route. It's hard to say without a config.
The second never met. Or noise on the air, or Mom's coolhackers, or problems with the link.
"Periodic breaks"

Sun May 12 12:52:56 2019 TLS: tls_process: killed expiring key

is updating the encryption keys.
If a connection break occurs, then openvpn usually waits 5 seconds before retrying the connection.