Connection refused problems with Merlin on ASUS RT-AC88U

[William Hudson]

My VPN setup to PrivateTunnel had been working fine for several weeks until last Tuesday, when our web browsers suddenly started to report 'connected refused' errors for most sites. Restarting the OpenVPN client in Merlin fixes it temporarily but since then it has not run 24 hours without the problem returning. Turning off the VPN client fixes the problem completely.

I raised a ticket with PrivateTunnel but all they could suggest was revoking my credentials and downloading a new .opvn config file. I did this but then the client failed to connect at all. For some reason, the protocol defaulted to TCP when it should have been UDP. Fixing that in the settings allowed the initial connection to the VPN servers, but the original problem continued. PrivateTunnel have not suggested anything new since - I have raised another ticket.

I don't know enough about OpenVPN to debug possible problems. There are some warning messages during the initial handshake and the hourly reset, but when the connection refused errors appear, there is usually nothing in the log of interest.

Attached is the initial part of their london.ovpn config file (the rest is certificates of various sorts) and the router log entries. The router is an ASUS RT-AC88U running Merlin 380.66_4, although it was 66_2 when the problems started. The upgrade appeared to make no difference.

 

[Xentrk]

My VPN setup to PrivateTunnel had been working fine for several weeks until last Tuesday, when our web browsers suddenly started to report 'connected refused' errors for most sites. Restarting the OpenVPN client in Merlin fixes it temporarily but since then it has not run 24 hours without the problem returning. Turning off the VPN client fixes the problem completely.

I raised a ticket with PrivateTunnel but all they could suggest was revoking my credentials and downloading a new .opvn config file. I did this but then the client failed to connect at all. For some reason, the protocol defaulted to TCP when it should have been UDP. Fixing that in the settings allowed the initial connection to the VPN servers, but the original problem continued. PrivateTunnel have not suggested anything new since - I have raised another ticket.

I don't know enough about OpenVPN to debug possible problems. There are some warning messages during the initial handshake and the hourly reset, but when the connection refused errors appear, there is usually nothing in the log of interest.

Attached is the initial part of their london.ovpn config file (the rest is certificates of various sorts) and the router log entries. The router is an ASUS RT-AC88U running Merlin 380.66_4, although it was 66_2 when the problems started. The upgrade appeared to make no difference.

I just noticed this is my 600th post!

My opinion of Private Tunnel is not high just for the fact they don't include instructions for installing/configuring their product on firmware other than DD-WRT. They have excluded a large market by leaving out pfSense, Tomato, Stock ASUS and ASUS Merlin.

I see they are pushing options down to the client and one is regneg-sec. In the web gui, set TLS Renegotiation Time to 0 (zero) and see if that helps. Here is more info from the openvpn 2.4 manual.

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

Also, are these duplicate UDP entries in the ovpn file you imported from Private Tunnel?

remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 443 tcp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp

There should only be one server entry. Correct? I mean you can only connect to one server at a time per client.

Another item is the socket-flags TCP_NODELAY. I see this error NOTE: setsockopt TCP_NODELAY=1 failed. This appears to apply to TCP connections according the OpenVPN 2.4 manual. But UDP is the preferred method for VPN performance. So I am not sure why they include this. You may want to experiment with removing this option after you first tried the other items and see if the failed message goes away.

 

[William Hudson]

I just noticed this is my 600th post!

My opinion of Private Tunnel is not high just for the fact they don't include instructions for installing/configuring their product on firmware other than DD-WRT. They have excluded a large market by leaving out pfSense, Tomato, Stock ASUS and ASUS Merlin.

I see they are pushing options down to the client and one is regneg-sec. In the web gui, set TLS Renegotiation Time to 0 (zero) and see if that helps. Here is more info from the openvpn 2.4 manual.

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

Also, are these duplicate UDP entries in the ovpn file you imported from Private Tunnel?

remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 443 tcp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp
remote uk-ln-001.privatetunnel.com 1194 udp

There should only be one server entry. Correct? I mean you can only connect to one server at a time per client.

Another item is the socket-flags TCP_NODELAY. I see this error NOTE: setsockopt TCP_NODELAY=1 failed. This appears to apply to TCP connections according the OpenVPN 2.4 manual. But UDP is the preferred method for VPN performance. So I am not sure why they include this. You may want to experiment with removing this option after you first tried the other items and see if the failed message goes away.

Thanks for that. I looked up their server address and they have 8 round-robin DNS entries so maybe they're trying to make use of those in some strange way?

I tried setting reneg-sec to 0 but my browser failed an hour or so later with a DNS error. I could look up the DNS in an external site, so it was just our router that couldn't resolve it. Turning off the OpenVPN client fixed the problem. BTW, the log still showed some key refresh every hour, just no 'soft reset'.

This morning I modified the London.opvn file to remove all but the first remote line. I also took out the TCP_NODELAY. On rebooting the router, my partner's remote desktop (from Windows) was unable to connect although my web browser was fine. As usual, turning off the OpenVPN client fixed it.

I wonder if the problem - which appeared from the blue at the end of last month - is due to the options being pushed to the client? There are a number of complaints from OpenVPN:

Jun 9 11:05:00 openvpn[1019]: SENT CONTROL [uk1.privatetunnel.com]: 'PUSH_REQUEST' (status=1)
Jun 9 11:05:00 openvpn[1019]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.9.0.1,ifconfig 10.9.3.245 255.255.0.0,client-ip 81.104.76.3,ping 8,ping-restart 40,reneg-sec 3600,cipher AES-128-GCM,compress lz4-v2,peer-id 79939,topology subnet,explicit-exit-notify,redirect-gateway def1,dhcp-option DNS 10.9.0.1,sndbuf 0,rcvbuf 0,socket-flags TCP_NODELAY,block-ipv6'
Jun 9 11:05:00 openvpn[1019]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: client-ip (2.4.2)
Jun 9 11:05:00 openvpn[1019]: Options error: option 'reneg-sec' cannot be used in this context ([PUSH-OPTIONS])
Jun 9 11:05:00 openvpn[1019]: Option 'explicit-exit-notify' in [PUSH-OPTIONS]:11 is ignored by previous <connection> blocks
Jun 9 11:05:00 openvpn[1019]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:17: block-ipv6 (2.4.2)
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: timers and/or timeouts modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: explicit notify parm(s) modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: compression parms modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Jun 9 11:05:00 openvpn[1019]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: --socket-flags option modified
Jun 9 11:05:00 openvpn[1019]: NOTE: setsockopt TCP_NODELAY=1 failed
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: --ifconfig/up options modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: route options modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: route-related options modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: peer-id set
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: adjusting link_mtu to 1625
Jun 9 11:05:00 openvpn[1019]: OPTIONS IMPORT: data channel crypto options modified
Jun 9 11:05:00 openvpn[1019]: Data Channel Encrypt: Cipher 'AES-128-GCM' initialized with 128 bit key
Jun 9 11:05:00 openvpn[1019]: Data Channel Decrypt: Cipher 'AES-128-GCM' initialized with 128 bit key
Jun 9 11:05:00 openvpn[1019]: TUN/TAP device tun12 opened
Jun 9 11:05:00 openvpn[1019]: TUN/TAP TX queue length set to 100
Jun 9 11:05:00 openvpn[1019]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jun 9 11:05:00 openvpn[1019]: /usr/sbin/ip link set dev tun12 up mtu 1500
Jun 9 11:05:00 openvpn[1019]: /usr/sbin/ip addr add dev tun12 10.9.3.245/16 broadcast 10.9.255.255
Jun 9 11:05:02 openvpn[1019]: /usr/sbin/ip route add 5.101.172.132/32 via 81.104.76.1
Jun 9 11:05:02 openvpn[1019]: /usr/sbin/ip route add 0.0.0.0/1 via 10.9.0.1
Jun 9 11:05:02 openvpn[1019]: /usr/sbin/ip route add 128.0.0.0/1 via 10.9.0.1
Jun 9 11:05:02 openvpn-routing: Skipping, client 2 not in routing policy mode
Jun 9 11:05:02 openvpn[1019]: Initialization Sequence Completed​