RV50 not connecting OpenVPN

Hi there,

trying out a RV50 for a potential client project. We have an OpenVPN server running, (Windows, Mac, Linux) clients can connect fine using certificates. Everything in the RV50 is set as in our .ovpn files which work perfectly on the clients.

Here it is:

client
dev tun
proto udp
remote server.tld 1194
float
comp-lzo yes
push "comp-lzo yes"
resolv-retry infinite 
nobind
persist-key 
persist-tun 
verb 3
auth SHA256
cipher AES-256-CBC
ca cacert.pem 
cert BenutzerB.pem
key BenutzerB-NOPASS.key

Passphrase was removed for the Key to avoid requesting passwords for the certificate.

In the RV50 OpenVPN-Setting we have


The username/password field are kept blank because we don’t need them.

And here comes the problem… How to tell the RV50 to connect to the VPN? According to the manual there’s nothing more to do. Apply the policy or reboot and that should be it.

But it is not obviously.

I checked the Log and even in verbose mode I can’t see any connection attempt. The VPN server sees an attempt from a device with an undefined CN. But it’s there in the RV50s settings as you can see in the screenshot above.

Aug 15 16:55:24 warning ALEOS_ALMS_LWM2M: Failed bootstrap, retrying in '40' seconds, '2' left
Aug 15 16:55:25 info ALEOS_SYSTEM_WDlog: Deregister '/tmp/alive/lwm2m_alive'
Aug 15 16:55:38 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:56:06 info ALEOS_SYSTEM_CSM: Adding All Notification for /lwm2N 
Aug 15 16:56:06 info ALEOS_SYSTEM_WDlog: Update Register '/tmp/alive/lwm2m_alive' (max error='2', period='120', action='kill')
Aug 15 16:56:11 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:56:14 warning ALEOS_ALMS_LWM2M: Failed bootstrap, retrying in '80' seconds, '1' left
Aug 15 16:56:15 info ALEOS_SYSTEM_WDlog: Deregister '/tmp/alive/lwm2m_alive'
Aug 15 16:56:35 info ALEOS_SYSTEM_WDlog: Deregister '/tmp/alive/lwm2m_alive'
Aug 15 16:56:38 info ALEOS_SYSTEM_WDlog: Register '/tmp/alive/msci_alive' (max error='2', period='300', action='kill')
Aug 15 16:56:38 info ALEOS_SYSTEM_CSM: Adding All Notification for /ANup 
Aug 15 16:56:44 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:57:16 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:57:49 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:58:22 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:58:55 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 16:59:28 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1
Aug 15 17:00:00 info ALEOS_SYSTEM_STS: send tunnel command: /usr/sbin/firewall settunnel 1 down> /dev/null 2>&1

In VPN-Confuration both outgoing (Management and Host) is allowed.

Just to make sure there’s nothing blocked by the cellular provider used for this test: connecting a laptop to the RV50s ethernet port and firing up OpenVPN connects instantly.

Firmware is 4.8.0. There is a 4.8.1 on the website but only for North America. It’s EMEA here.

I do believe I’m missing something…

Any hints, folks?

Hi pbk,

You need to increase the log level or verbosity to be able to view VPN information.
This can be done in AceManager under Admin > Configure Logging.

Regards,
Nick

The Log in my post was created with VPN verbosity set to “Debug”.

/edit
Ah! There’s a note in the manual… “If you are debugging a VPN or LAN setup, the relevant information is only displayed in the Linux Syslog.” – I’ll fire it up when I’m back at the office later today and give it a try.

OK… Loggin the Linux Syslog we get

Aug 16 12:24:33 notice openvpn-1[8830]: SIGUSR1[soft,tls-error] received, process restarting
Aug 16 12:24:33 notice openvpn-1[8830]: Restart pause, 2 second(s)
Aug 16 12:24:35 warning openvpn-1[8830]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Aug 16 12:24:35 notice openvpn-1[8830]: LZO compression initialized
Aug 16 12:24:35 notice openvpn-1[8830]: Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 16 12:24:35 notice openvpn-1[8830]: Data Channel MTU parms [ L:1574 D:1400 EF:74 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 16 12:24:35 notice openvpn-1[8830]: Fragmentation MTU parms [ L:1574 D:1300 EF:73 EB:135 ET:1 EL:0 AF:3/1 ]
Aug 16 12:24:35 notice openvpn-1[8830]: Local Options String: 'V4,dev-type tun,link-mtu 1574,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-client'
Aug 16 12:24:35 notice openvpn-1[8830]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1574,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher AES-256-CBC,auth SHA256,keysize 256,key-method 2,tls-server'
Aug 16 12:24:35 notice openvpn-1[8830]: Local Options hash (VER=V4): 'aa803726'
Aug 16 12:24:35 notice openvpn-1[8830]: Expected Remote Options hash (VER=V4): '25cf3a87'
Aug 16 12:24:35 notice openvpn-1[8830]: Socket Buffers: R=[163840->131072] S=[163840->131072]
Aug 16 12:24:35 notice openvpn-1[8830]: UDPv4 link local: [undef]
Aug 16 12:24:35 notice openvpn-1[8830]: UDPv4 link remote: 87.xxx.xxx.xxx:1194
Aug 16 12:24:35 notice openvpn-1[8830]: TLS: Initial packet from 87.xxx.xxx.xxx:1194, sid=4966da65 9387e5bc
Aug 16 12:24:35 notice openvpn-1[8830]: VERIFY OK: depth=1, /C=DE/ST=xxxxxxxxx/O=xxxxxxxxx/CN=xxxxxxxx/emailAddress=support@xxxxxxxx.com
Aug 16 12:24:35 notice openvpn-1[8830]: VERIFY nsCertType ERROR: /C=DE/ST=xxxxxxxxx/L=xxxxxx/O=xxxxxxxxxx/CN=Server/emailAddress=support@xxxxxxxx.com, require nsCertType=SERVER
Aug 16 12:24:35 err openvpn-1[8830]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Aug 16 12:24:35 err openvpn-1[8830]: TLS Error: TLS object -> incoming plaintext read error
Aug 16 12:24:35 err openvpn-1[8830]: TLS Error: TLS handshake failed
Aug 16 12:24:35 notice openvpn-1[8830]: TCP/UDP: Closing socket
Aug 16 12:24:35 notice openvpn-1[8830]: SIGUSR1[soft,tls-error] received, process restarting
Aug 16 12:24:35 notice openvpn-1[8830]: Restart pause, 2 second(s)

To prove that other clients do connect properly…

2017-08-16 14:55:07: Viscosity Mac 1.7.3 (1412)
2017-08-16 14:55:07: Viscosity OpenVPN Engine Started
2017-08-16 14:55:07: Running on macOS 10.12.6
2017-08-16 14:55:07: ---------
2017-08-16 14:55:07: State changed to connecting
2017-08-16 14:55:07: Checking reachability status of connection...
2017-08-16 14:55:08: Connection is reachable. Starting connection attempt.
2017-08-16 14:55:08: OpenVPN 2.4.3 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jun 21 2017
2017-08-16 14:55:08: library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.09
2017-08-16 14:55:08: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2017-08-16 14:55:08: TCP/UDP: Preserving recently used remote address: [AF_INET]87.xxx.xxx.xxx:1194
2017-08-16 14:55:08: UDP link local: (not bound)
2017-08-16 14:55:08: UDP link remote: [AF_INET]87.xxx.xxx.xxx:1194
2017-08-16 14:55:08: State changed to authenticate
2017-08-16 14:55:09: [Server] Peer Connection Initiated with [AF_INET]87.xxx.xxx.xxx:1194
2017-08-16 14:55:10: Opening utun (connect(AF_SYS_CONTROL)): Resource busy
2017-08-16 14:55:10: Opened utun device utun1
2017-08-16 14:55:10: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2017-08-16 14:55:10: /sbin/ifconfig utun1 delete
2017-08-16 14:55:10: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2017-08-16 14:55:10: /sbin/ifconfig utun1 172.16.0.2 172.16.0.2 netmask 255.255.255.0 mtu 1500 up
2017-08-16 14:55:10: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2017-08-16 14:55:10: Initialization Sequence Completed
2017-08-16 14:55:11: DNS mode set to Split
2017-08-16 14:55:11: State changed to connected

To me it looks as if the RV50 is rejecting the connection attempt because the nsCertType=SERVER is not set. I don’t want to and I don’t need to.

So question is: is there any way to tell the RV50 to not check the CertType?

Hi pbk,

That’s correct. The RV50 is checking for Net Scape extensions. Unfortunately, there is no way to disable this checking. There is a plan to remove this in the next major release. For now, I recommend adding the NSCERT on the server side to address the issue.

Regards,
NIck

To sum it up: Sierra sells devices with a broken OpenVPN client implementation (the server is always the master, the client always the slave. A client can’t tell the server how it has to behave. It never worked that way and it never will).

And there’s no Root SSH access to fix their broken stuff by ourselves. Bummer.

1 Like

As someone who has just spent the best part of A WEEK trying to get an RV50 to connect to an OpenVPN server, I feel your pain. At least this thread gets some kind of attention from… someone? Having found this thread, and after much wrangling I finally managed to get the RV50 to send its VPN syslog entries to another host (it turns out you must enable “Linux syslog” > “Display” in order for this to work, otherwise the openvpn log is absent from the syslog output, regardless of what logging level you set it to). At last I could see what the problem was in plain text:

2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] VERIFY nsCertType ERROR: /CN=server, require nsCertType=SERVER
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Oh the hours… the relentless trial and error, the digging through vast volumes of obtuse and archaic documentation, the trawling of commit logs and firmware release notes, the repeated regenerating of server and client keys, at every stage having to reboot the RV50 to try again (177 times in the last week, according to my reports), the ever dashed hopes that a solution might have been found. You really have to be as stubborn as an ox and patient as a monk to get anywhere with this crap. And what does the error mean? It means that the OpenVPN client on the RV50 insists on checking for the presence of an X509 extension which was deprecated in OpenSSL in 2014, with the following message appearing in the openssl.cnf file:

# nsCertType omitted by default. Let's try to let the deprecated stuff die.

Indeed. Do you mind, Sierra?

In order to spare any future comers a similarly tortuous journey: I solved the issue of the missing Netscape extension by adding

set_var EASYRSA_NS_SUPPORT yes

to easy-rsa’s “vars” file before generating the server certficiate - which now contains

X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            Netscape Comment: 
                Easy-RSA Generated Certificate
            Netscape Cert Type: 
                SSL Server

and thereby satisfies the RV50’s retrograde certificate verification. But really Sierra, get with the ******* programme already. Netscape gone dead long time, and most of their proprietary crap went with them.

Correction: The OpenVPN client on the RV50 is still not able to connect properly:

Aug 26 15:31:55 cloud ovpn-server[659]: 44.55.66.77:43198 IP packet with unknown IP version=0 seen

It would seem this is because the OpenVPN client (and probably OpenSSL as well) on the RV50 is five years out of date, and incompatible with OpenVPN servers > v2.1. As further illustrated by these warnings:

Aug 26 15:54:55 cloud ovpn-server[3990]: 44.55.66.77:43198 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1573'
Aug 26 15:54:55 cloud ovpn-server[3990]: 44.55.66.77:43198 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

This is really bad Sierra; you are shipping an OpenVPN client with known and very serious security vulnerabilities, for example Heartbleed. Never mind me, but it scares me to think that this is a device which is intended to be used in “first respondent” type vehicles and critical infrastructure. Are your customers aware of the risks you are exposing them to, I wonder?

It looks like this problem is fixed in ALEOS 4.9.0 firmware update. They have added a --ns-cert-type drop down in the OpenVPN settings.

One question I have is, for OpenVPN server such as PFSense, am I supposed to connect using Peer to Peer (shared key) or Peer to Peer SSL/TLS ? This is for a Site to Site kind of VPN Setup.

For Peer to Peer Shared key, it doesn’t look like there is any way to put in the IPv4 Remote networks in the RV50:
https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

However, for Peer to Peer (SSL/TLS), the IPv4 Remote networks are pushed to the client via an iroute:
https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)

Is Peer to Peer (SSL/TLS) setup the only way the RV50 OpenVPN will work?

I know that the Roadwarrior setup doesn’t work either.

1 Like

Okay, I have gotten the PFSense Peer to Peer (SSL/TLS) setup to work and connect successfully with the RV50 OpenVPN client. However, not much is routable to the VPN tunnel it seems.

-From the RV50 Ethernet DHCP Addresses I can ping the OpenVPN Client Tunnel IP (10.0.8.2). However, I cannot ping anything else on the 10.0.8.0/24 tunnel network. I believe the PFSense OpenVPN server gets a Tunnel IP (10.0.8.1), which I cannot ping or vice versa.
-From RV50 Ethernet DHCP Addresses I cannot ping any local LAN networks on the PFSense OpenVPN server.
-From PFSense OpenVPN server, I cannot ping any Remote LAN networks on the RV50 through the VPN tunnel.

Do I need to add a policy route? Is there any special routing or firewall settings on the RV50 that I need to add?

There doesn’t seem to be a route from the Ethernet port to anything through the VPN tunnel, except for the tunnel client itself. How to force all local host traffic through the Tunnel?

Any help would be appreciated figuring out what needs to be changed on the RV50.

1 Like

Okay I figured out the issue. The OpenVPN server has to match the RV50 OpenVPN Client advanced settings verbatim. In my case the RV50 OpenVPN advanced settings are such:

Tunnel-MTU: 1500
MSS Fix: 1400
Fragment: 1300

Thus, the PFSense OpenVPN server needs the exact same settings. Under OpenVPN server-> Advanced Configuration I added the following:

tun-mtu 1500;mssfix 1400;fragment 1300

Once I put in the above settings, voila everything is pingable!

1 Like

And 3 years later, they still can’t implement a compliant OpenVPN client, and they continue to publish that it works with OpenVPN. Hacking this garbage device and lowering the security of the server is the worst idea ever. Since they seem to think that these devices will control industrial equipment, which is ripe for hacking by nation state actors.

The product is a total pile of junk.