OpenVPN client reconnect every 10 seconds

[mshakurov]

Softether VPN Server installed on ubuntu from downloads page.

- ovpn file was generated from SE VPN Server Manager

- OpenVPN Client connect successfully, with log:
[Oct 4, 2024, 20:34:51] OPTIONS:
0 [ping] [3]
1 [ping-restart] [10]
...
[Oct 4, 2024, 20:34:51] PROTOCOL OPTIONS:
cipher: AES-128-CBC
digest: SHA1
key-derivation: OpenVPN PRF
compress: NONE
peer ID: -1
...
[Oct 4, 2024, 20:34:52] Connected via TUN_WIN
[Oct 4, 2024, 20:34:52] EVENT: CONNECTED username@111.111.111.111:1194 (111.111.111.111) via /UDP on TUN_WIN/192.168.30.13/ gw=[192.168.30.14/] mtu=(default)

- Then, OpenVPN Client reconnects every 10 seconds - an entry suddenly appears in log:

[Oct 4, 2024, 20:35:02] Session invalidated: KEEPALIVE_TIMEOUT
[Oct 4, 2024, 20:35:02] Client terminated, restarting in 2000 ms...
[Oct 4, 2024, 20:35:02] SetupClient: signaling tun destroy event
[Oct 4, 2024, 20:35:04] EVENT: RECONNECTING
[Oct 4, 2024, 20:35:04] EVENT: RESOLVE
[Oct 4, 2024, 20:35:04] Contacting 37.221.127.129:1194 via UDP
...

And it happens in an endless loop

This started happening a couple of weeks ago. And I have not updated either the server or the OpenVPN client. I even had a router connected via OpenVPN, and the entire local network used a VPN, and I did not update the router or change the settings.

[solo]

Your government has started blocking VPNs. Try SE client instead, it may still work.

[mshakurov]

On desktop PCs I already use SE Client. But I wanted to use a router that only supports openvpn, pptp and lttp. SE Server supports only openvpn from this list. Is there a tricky way to somehow fine-tune, sharpen the settings in SE Server and in the ovpn file/client?
I don't want to bother you with giving me a detailed answer, I just hope you have a "yes" answer to my question. Well, or "No", then I won't try to configure the openvpn client.

[solo]

Yes - "How to make a Tunnel" - this is the way.

[mshakurov]

Yes - "How to make a Tunnel" - this is the way.

Sorry, but if the middle SE server is located in the public network of the blocking country, then this method does not work because the connection via the OpenVPN protocol to this middle SE server is blocked.
I tried to install a middle SE Server on a local network, even in a virtual machine on Hyper-V, and then the connection using the OpenVPN client worked. But the middle server in the local network cannot be used as a target vpn server for connecting from a router that outputs the entire local network to the Internet.
The only solution is either to change the router that supports wireguard or sstp, or to put another output router between the main router and the Internet, with its own small local network. In the network of the output router, you can place a middle SE server (on a VM or a physical one), and then the main router will connect to this middle SE server via OpenVPN, and through it access the Internet through a tunnel to the final SE server.

[solo]

Sorry, but if the middle SE server is located in the public network of the blocking country, then this method does not work because the connection via the OpenVPN protocol to this middle SE server is blocked.

No, it is blocked only on the country's international connections, of course.

[mshakurov]

No, it is blocked only on the country's international connections, of course.

I mean that chain does not break at all:
[Point 1]. Client in blocking country
-> connection via local subnet (not via ISP), using OpenVPN protocol ->
[Point 2]. SE Server on Client's PC on the same local subnet
-> cascading connection via ISP of the blocking country, using some SE Protocol (tunnel) ->
[Point 3]. Target SE Server in non-blocking country.
The connection is absolutely stable and does not break.

But such a chain ends already between points 1 and 2:
[Point 1]. Client in blocking country
-> connection via the Internet Service Provider (ISP) of the same blocking country, using the OpenVPN protocol ->
[Point 2]. SE Server on VPS server in the same blocking country
-> cascading connection to non blocking country via some SE Protocol (tunnel) ->
[Point 3]. Target SE Server in non-blocking country.
After the connection to the SE Server at Point 2 was successfully established, and records of successful connection appeared in the logs of the SE Server 2 and the OpenVPN client, packets were no longer registered on SE Server at Point 2. After some time, a record appeared in the server logs stating that the connection was terminated at the initiative of the client. The client logs also show an entry about the timeout gap (which I wrote about in the first post).
I am sure that this chain breaks between points 1 and 2, and not on international connections. The systems of blocking country recognize the OpenVPN protocol and interrupt the connection on the ISP equipment or on the country's Internet lines.

[solo]

This is the first report of such widespread interference. OpenVPN is an easy target and your overlords have decided to kill it on national level too. It is probably useless but check different TCP, UDP and atypical port number connections.