OpenVPN Support Forum

Good afternoon. Faced a problem on Xiaomi and Tenda300 routers: it turns off after a while by keep alive timeout
To solve this problem, we gave a new client profile with keepalive settings, but this did not help
I also turned it off in the Connection Timeout settings, but that didn't help either.
What settings on the router can in principle affect this?

For router specific settings you should ask the router manufacturer as we don't know if the OpenVPN implementation shipped with the router has been modified or not. They should have all the info required to debug this.

However, keepalive timeout is normally due to network disruptions. So for some reason the connection may be suddenly breaking up.

ordex wrote: ↑

Fri Nov 18, 2022 9:22 am

For router specific settings you should ask the router manufacturer as we don't know if the OpenVPN implementation shipped with the router has been modified or not. They should have all the info required to debug this.

However, keepalive timeout is normally due to network disruptions. So for some reason the connection may be suddenly breaking up.

We just don't find network outages in the traffic dump. And this is a fairly simple equipment, according to which the manufacturer is unlikely to answer

Ok, then for starters it would make sense to share client and server log so that we can see what is happening.
It'd be nice if you could add "verb 4" to your config files, so we can see some more details.

ordex wrote: ↑

Fri Nov 18, 2022 11:24 am

Ok, then for starters it would make sense to share client and server log so that we can see what is happening.
It'd be nice if you could add "verb 4" to your config files, so we can see some more details.

We received the following messages from clients with verb 6. After successful authorization, some time passes and here are the logs (I hid the client's ip addresses and logins):
13:48 connection
13:56 disconnected
⏎[Nov 18, 2022, 13:48:58] Connected via TUN_WIN
⏎[Nov 18, 2022, 13:48:58] EVENT: CONNECTED user@server:503 (ipaddress) via /UDPv4 on TUN_WIN/ipaddress/ gw=[ipaddress/]⏎[Nov 18, 2022, 13:56:54 ]Session invalidated: KEEPALIVE_TIMEOUT
⏎[Nov 18, 2022, 13:56:54] Client terminated, restarting in 2000 ms...
⏎[Nov 18, 2022 13:56:54] SetupClient: signaling tun destroy event
⏎[Nov 18, 2022, 13:56:56] EVENT: RECONNECTING ⏎[Nov 18, 2022, 13:56:56] EVENT: RESOLVE ⏎[Nov 18, 2022, 13:56:56] Contacting ipaddress:503 via UDP
⏎[Nov 18, 2022 13:56:56] EVENT: WAIT ⏎[Nov 18, 2022 13:56:56] WinCommandAgent: transmitting bypass route to ipaddress
{
"host" : "ipaddress",
"ipv6" : false
}

the server still has verb 3:
2022-11-18 13:49:50 username /5.167.34.207:57152 [username ] Inactivity timeout (--ping-restart), restarting
['CLIENT:DISCONNECT,97259', 'CLIENT:ENV,script_type=client-disconnect', 'CLIENT:ENV,time_duration=3613', 'CLIENT:ENV,bytes_sent=18976365', 'CLIENT:ENV,bytes_received=5050812' , 'CLIENT:ENV,trusted_port=57152', 'CLIENT:ENV,trusted_ip=5.167.34.207', 'CLIENT:ENV,ifconfig_pool_netmask=255.255.248.0', 'CLIENT:ENV,ifconfig_pool_remote_ip=ipaddress', 'CLIENT:ENV, time_unix=1668764977', 'CLIENT:ENV,time_ascii=2022-11-18 12:49:37', 'CLIENT:ENV,common_name=username ', 'CLIENT:ENV,session_id=id ', 'CLIENT:ENV,session_state =Initial', 'CLIENT:ENV,untrusted_port=port', 'CLIENT:ENV,untrusted_ip=5.167.34.207', 'CLIENT:ENV,username=username ', 'CLIENT:ENV,IV_BS64DL=1', 'CLIENT:ENV ,IV_SSL=OpenSSL_1.1.1n__15_Mar_2022', 'CLIENT:ENV,IV_HWADDR=2c:56:dc:3f:bb:bb', 'CLIENT:ENV,']

And in the traffic dump, he has the following situation
And in the traffic dump, the following happens (I describe, as I could not attach a screenshot):
log arp who has adress ? tell address-server
Looks like he's lost at this point.

Was the dump taken on the tunnel or on the internet interface?
I presume on the latter, since the tunnel is L3 and has no ARPs.

What you are describing simply indicates a lack of connectivity to the Internet/router/modem.

ordex wrote: ↑

Fri Nov 18, 2022 1:40 pm

Was the dump taken on the tunnel or on the internet interface?
I presume on the latter, since the tunnel is L3 and has no ARPs.

What you are describing simply indicates a lack of connectivity to the Internet/router/modem.

The dump was taken on the user's PC while disconnecting from the VPN