Asus RT-N66U + USB modem 4G + openVPN = daemon.err openvpn[1071]: Connection reset, restarting [0]

Installing and Using OpenWrt
1

I am ready to give up wi-fi, since it works badly on Asus RT-N66U.

I'm trying to create a stable connection via VPN.

all traffic must pass through vpn, without exceptions and leaks.

All I could achieve is NOT a stable connection.

after connecting vpn, the connection is constantly disappearing. (every 6-10 minutes)

triggered daemon.err openvpn [1071]: Connection reset, restarting [0]

connection is restored, then disappears again

triggered daemon.err openvpn [1071]: Connection reset, restarting [0]

connection is restored, then disappears again

triggered daemon.err openvpn [1071]: Connection reset, restarting [0]

connection is restored, then disappears again

.....

I do not know what the reason is!?

I have system and kernel logs, I can upload them.

I can lay out the settings in the UCI format from the configuration files:

/etc/config/firewall
/etc/config/network
/etc/config/...
/etc/config/.

I use config in /etc/config/openvpn

config openvpn "custom_config"
       option enabled "1"
       option config "./etc/openvpn/my-vpn.conf"

in kernel log, the following is entering me into a stupor:

[   78.484948] random: crng init done
[   78.488484] random: 3 urandom warning(s) missed due to ratelimiting

similar lines are present in the system log:

 06:16:52 kern.notice kernel: [   78.484948] random: crng init done
 06:16:52 kern.notice kernel: [   78.488484] random: 3 urandom warning(s) missed due to ratelimiting

I tried different configurations of the client .conf files of openvpn
configurations work fully and stably with the existing lte modem

stability disappears only when moving .conf + usb modem to the router

I am using the openWRT build 18.06.2

I also tried 17.01.6 and 15.05.1

I tried DD-WRT, Tomato, Asuswrt-Merlin. they do not suit me. and do not satisfy

I do not know whether this configuration of the firewall can affect the stability of the VPN connection

444444

I am interested in all possible and most universal ways of the so-called Kill-Switch

if the above firewall configuration adversely affects performance
I would be grateful for giving various examples that implement guaranteed blocking of traffic past vpn

in other words, my problem can be described as:

I get the following logs from daemon.notice openvpn:

Initialization Sequence Completed

    5-10 minute good connect

Connection reset, restarting 
...
..
.
Initialization Sequence Completed

     6-12 minute good connect

Connection reset, restarting 
...
..
.
Initialization Sequence Completed

     5-10 minute good connect

Connection reset, restarting 
...
..
.
Initialization Sequence Completed

      7-9 minute good connect

Connection reset, restarting 
...
..
.
Initialization Sequence Completed
2

If I understand properly your wan uplink is a 4G connection. Is that stable all the time or does it flap?
Could you post the OpenVPN configuration?

3

Yes. absolutely correct. wan is 4g lte modem
on a computer, this modem and the configuration file vpn work very stably. for 20-30 hours, without cliffs
I just rename .ovpn to .conf
and load it through custom_config

the very first template after installing openvpn-openssl and luci-app-openvpn is custom_config
I just open /etc/config/openvpn
there are listed all these three patterns that are displayed in LUCI
custom_config
sample_server
sample_client

You can specify any path in the custom_config and any name of the openVPN configuration file. I think it will even accept the .ovpn extension, but I renamed my configuration file to .conf
and did not change the path
it defaults to

/etc/openvpn/my-vpn.conf

I took my name_file.ovpn
renamed to my-vpn.conf
and threw it in

/etc/openvpn/

when I ran into these reconnects :"Connection reset, restarting"
I thought he didn’t like my configuration. but it turned out that even other configuration files lead to the same Connection reset, restarting

option - I did not try to fill in all the parameters via GUI Luci
, for the reason that I have a lot of configuration files,

I would gladly fill out by hand if someone convincingly suggested that this could be the reason for the reconnections

But I think and I hope that the firmware is eating the same and loading

config openvpn "custom_config"
       option enabled "1"
       option config "./etc/openvpn/my-vpn.conf"

as well as
and fill through UCI :

example patterns sample_client :

config openvpn 'sample_client'
	option client '1'
	option dev 'tun'
	option proto 'udp'
	list remote 'my_server_1 1194'
	option resolv_retry 'infinite'
	option nobind '1'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option ca '/etc/openvpn/ca.crt'
	option cert '/etc/openvpn/client.crt'
	option key '/etc/openvpn/client.key'
	option compress 'lzo'
	option verb '3'

although I thought that filling all the parameters through
option
and dividing all certificates and keys into separate files and uploading them also via option - it could work somewhat easier for the system

but logic tells me that no gravity should be added if I simply point the way to the configuration file and its name

anyway, I tried different configuration files and the problem remained

the reference configuration necessary for me is as follows

client
dev tun

setenv FORWARD_COMPATIBLE 1

key-direction 1
cipher AES-256-CBC
reneg-sec 3600
resolv-retry infinite
nobind
persist-key
persist-tun
pull
mssfix

comp-lzo
keepalive 30 120

block-outside-dns
auth-nocache
remote-cert-tls server
verb 1

tun-mtu 1500
push-peer-info
auth-nocache
remote-cert-tls server


remote 199.199.99.199 443 tcp


<ca>
-----BEGIN CERTIFICATE-----
123213232132323
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
456546546546546546546
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN EC PARAMETERS-----
2190219021
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
9879789879879879879879
-----END EC PRIVATE KEY-----
</key>

<tls-auth>
-----BEGIN OpenVPN Static key V1-----
8564308563495634562340
-----END OpenVPN Static key V1-----
</tls-auth>

this is all the contents of the configuration file. I tried to find a solution requiring minimal changes. so that you can simply specify the path to the file by copying it in advance to the router in the desired folder. this is a very convenient way

4

Since the connection is established and works fine for some time there should not be any problem with the configuration files, nor should it matter if you use the .ovpn or .conf
You could raise the verbosity level from 1 to 5 maybe any see what will be the reason for the disconnect. Also leave a ping running from the OpenWrt router to some server on the internet, for example 8.8.8.8, to verify that internet connection is not dropping.
Just one more remark, I ran into some issues after upgrading to the latest OpenWrt version with comp-lzo option and had to switch to lz4.

5

I put the mtr (My Traceroute) package on the router and connected via telnet to launch it. and it shows that at some point the packet losses begin and if nothing is done, then the losses stop. connection is restored.
Unfortunately, there is only one access to the Internet. I drink coffee from time to time, read and search for answers, and then turn off the modem and mess with the router. I want to add options for testing and then reconnect the modem and try everything. such a plan)
thanks for option –verb I did not know :thinking:

6

Windows-specific, remove.

Redundant, remove.

Potentially problematic, remove.

Duplicate, remove.

Disable if possible.

Try udp if possible.

Change to tun0 to avoid wrong zone assignment.

Increase the log verbosity.

1 Like
7

Thanks for the advice. thanks to them, I found out the following:
By changing remote .. tcp to remote .. udp, you can ensure that the connection will not reconnect
Running mtr on a laptop connected to the router, I found out that packet loss is also on the udp connection, but these losses apparently do not cause reconnections. losses are less pronounced. they are. but they do not invoke reconnections.
and fewer. Probably tcp does not imply continuation of work when packets are lost and the openvpn daemon initiates a reconnection and during the reconnection the loss of packets becomes more pronounced as the connection becomes inactive and it takes time to reconnect. with udp, the losses are swallowed and when viewing sites the problems are not particularly noticeable. Although the speed at udp seems to be somewhat worse. and probably problems when watching a video on yotube

an error also occurs in the system log:

 06:16:52 kern.notice kernel: [   86.010612] random: crng init done
 06:16:52 kern.notice kernel: [   86.014147] random: 3 urandom warning(s) missed due to ratelimiting

and similar in the kernel log:

[   86.010612] random: crng init done
[   86.014147] random: 3 urandom warning(s) missed due to ratelimiting

in case of udp connection, the error becomes the last entry in the log after the connection is established

in the case of tcp, the last entries tell you about reconnecting the connection.
and in the system log the data about the error random: crng init done are moved to the middle of the log

in the kernel log for any connection. and udp and tcp.
the last entry is this error

random: crng init done

and

random: 3 urandom warning(s) missed due to ratelimiting

I honestly do not know whether to pay attention to this error or not. the reason is it or something else.

because the router has a similar openvpn package and it should work in the same way as the one installed on the computer

and when connecting openvpn on a computer, I do not need to make any modifications to the configuration file.

8

https://openwrt.org/docs/guide-user/services/rng