Ping fails with "IP packet with unknown IP version=0 seen"

etaoin

Having finally managed to get my client (a Sierra Wireless AirLink RV50 3G/4G router) to connect to my OpenVPN server, I'm still facing some issues. I get warnings about "link-mtu" and "mtu-dynamic" mismatches, which I think I can figure out on my own, but there's one thing I'm completely stuck on: pings from the client do not get a response from the server, but instead I see a warning in the server log about "IP packet with unknown IP version=0 seen". Now I assume this has something to do with IPv4 vs IPv6, and that (again) the AirLink client is the guilty party (shakes fist silently at Sierra Wireless). Basically, my interpretation is that the AirLink sends an IPv4 ping but fails to set the "version" correctly, and hence it's rejected by OpenVPN server. Is this correct, and - more importantly - what can I do to resolve it? There are no settings to do with IP version available in the client configuration.

Edit: As a test, I have completely disabled IPv6 on the server (ipv6.disable=1 kernel param), and the log reflects this:

Aug 26 15:31:55 cloud ovpn-server[659]: MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)

But the problem remains the same.

TinCanTech

Using this:

etaoin wroteSierra Wireless AirLink RV50 3G/4G router

With this version of openvpn:

RV50 openvpn-1[8692] NOTE: OpenVPN 2.1

Which is at least 5 years old, probably older.

Connecting to this:

etaoin wrotemy OpenVPN server

With this version of openvpn:

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017

There has been a huge amount of development in openvpn in the last five years ..
You must upgrade your router.

etaoin

TinCanTech wrote
There has been a huge amount of development in openvpn in the last five years ..
You must upgrade your router.

I understand what you are saying, trust me, I really do. But this is the equipment I have to work with. I have no leverage with Sierra Wireless - in fact they won't even respond to my queries. The router in question is a current model, launched only a year or two ago, and I have installed the latest firmware, which is from July this year. Clearly, the fault is entirely on Sierra's side and it is they who should resolve these problems, by releasing a firmware with an up to date OpenVPN client. But they won't. Please have some sympathy with my situation. Unless I can get the current version of OpenVPN server to become backwards compatible through configuration alone I will have no choice but to install an older version of it. If it comes to that, perhaps you can advise, based on the issues I'm having and the version of the client (2.1), which version of OpenVPN server I should be running to maximise the chances of a successful connection?

TinCanTech

etaoin wroteUnless I can get the current version of OpenVPN server to become backwards compatible through configuration alone I will have no choice but to install an older version of it.

You will not get v2.3.x to work correctly and securely with v2.1.x .. which means you will probably have to use an old version on your server.

Try this:
http://build.openvpn.net/downloads/releases/

Be warned : All old versions of openvpn are known to have security flaws : eg. Heartbleed etc.

Note: MTU problems are still present in the most recent release, so you may have to just live with those.

etaoin

Thank you.

TinCanTech wroteYou will not get v2.3.x to work correctly and securely with v2.1.x .. which means you will probably have to use an old version on your server.

I think I already have a working connection between the 2.1 client and the 2.3 server, and I think this connection is secure by current standards. MTU issues aside, the only thing that's causing problems at this point are the dropped pings, as explained in the first post of this thread. Short of downgrading to an older and insecure version of OpenVPN server, which is not a particularly attractive option - doubly so considering the work involved - I see two other options: one, fix the problem through the server side configuration, two, I simply disable pings from the client (by setting "Ping interval" to zero) and work around their absence.

etaoin

Just for completeness, and in case anyone is wondering, here's what an incoming connection from the RV50 currently looks like (at verb 3):

Aug 26 16:50:36 cloud ovpn-server[3063]: 44.55.66.77:36953 TLS: Initial packet from [AF_INET]44.55.66.77:36953, sid=f7c4f27c 4bc6db4c
Aug 26 16:51:09 cloud ovpn-server[3063]: 44.55.66.77:36953 CRL CHECK OK: CN=ChangeMe
Aug 26 16:51:09 cloud ovpn-server[3063]: 44.55.66.77:36953 VERIFY OK: depth=1, CN=ChangeMe
Aug 26 16:51:09 cloud ovpn-server[3063]: 44.55.66.77:36953 CRL CHECK OK: CN=raven
Aug 26 16:51:09 cloud ovpn-server[3063]: 44.55.66.77:36953 VERIFY OK: depth=0, CN=raven
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1573'
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 26 16:51:30 cloud ovpn-server[3063]: 44.55.66.77:36953 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 26 16:51:31 cloud ovpn-server[3063]: 44.55.66.77:36953 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Aug 26 16:51:31 cloud ovpn-server[3063]: 44.55.66.77:36953 [raven] Peer Connection Initiated with [AF_INET]44.55.66.77:36953
Aug 26 16:51:31 cloud ovpn-server[3063]: raven/44.55.66.77:36953 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Aug 26 16:51:31 cloud ovpn-server[3063]: raven/44.55.66.77:36953 MULTI: Learn: 10.8.0.2 -> raven/44.55.66.77:36953
Aug 26 16:51:31 cloud ovpn-server[3063]: raven/44.55.66.77:36953 MULTI: primary virtual IP for raven/44.55.66.77:36953: 10.8.0.2
Aug 26 16:51:33 cloud ovpn-server[3063]: raven/44.55.66.77:36953 PUSH: Received control message: 'PUSH_REQUEST'
Aug 26 16:51:33 cloud ovpn-server[3063]: raven/44.55.66.77:36953 send_push_reply(): safe_cap=940
Aug 26 16:51:33 cloud ovpn-server[3063]: raven/44.55.66.77:36953 SENT CONTROL [raven]: 'PUSH_REPLY,dhcp-option DNS 84.66.74.24,dhcp-option DNS 84.66.74.25,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)

TinCanTech

etaoin wrote think I already have a working connection between the 2.1 client and the 2.3 server, and I think this connection is secure by current standards

It is not secure by current standards.

etaoin wroteI see a warning in the server log about "IP packet with unknown IP version=0 seen"

That is your client sending encrypted VPN packets containing the tunnelled data payload but the server is rejecting it because it is of an unknown version .. Version Zero .. Your client is missing some crucial updates.

etaoin wroteShort of downgrading to an older and insecure version of OpenVPN server, which is not a particularly attractive option - doubly so considering the work involved - I see two other options: one, fix the problem through the server side configuration,

Not an option that I am aware of ..

etaoin wrotetwo, I simply disable pings from the client (by setting "Ping interval" to zero) and work around their absence

and what about actual data .. which is transmitted over the same channel as the ping .. ?

No matter what you do, I guarantee you that your VPN will not be secure ..
but you are welcome to believe what ever you want to believe .. Neo

ciao :mrgreen:

etaoin

I just want to be able to access the system connected to the RV50 from outside. That's all. It's mainly about overcoming the limitations of a NATed dynamic IP provided by the mobile network I'm connecting to. Despite knowing basically nothing about how to set one up, I assumed a VPN would be the way to go. It is now two weeks later, and I very much regret this assumption.

Thank you for all your generous help, you have been most gracious and kind. I will remember our conversation fondly, as a fine example of the helpful attitude one occasionally finds on the internet. If only more people had your patience, empathy, knowledge and understanding.

TinCanTech

The only real mistake you have made is acquiring a router which you cannot administer.

Use the router as a simple router and have a client inside the LAN provide the VPN end point.

etaoin

TinCanTech wroteThe only real mistake you have made is acquiring a router which you cannot administer.

Use the router as a simple router and have a client inside the LAN provide the VPN end point.

Agreed.

etaoin

TinCanTech wroteUse the router as a simple router and have a client inside the LAN provide the VPN end point.

I've been reluctant to do this for two reasons: first, the only "always on" system behind the router is a Raspberry Pi 2, with limited capacity in every respect, secondly, I wanted other devices on the same network to be able to use the VPN without having to jump through any hoops. I could add as a third reason, that I paid good money for the RV50 precisely because I hoped to use it as a VPN endpoint (amongst other things). Should have done more research - others be warned. But yes, reluctantly, this now looks like the best option, at least until Sierra Wireless update their firmware with an OpenVPN client from the modern era (hell may well freeze over before that happens, far as I can tell).

axelf911

etaoin wrote
TinCanTech wroteUse the router as a simple router and have a client inside the LAN provide the VPN end point.
I've been reluctant to do this for two reasons: first, the only "always on" system behind the router is a Raspberry Pi 2, with limited capacity in every respect, secondly, I wanted other devices on the same network to be able to use the VPN without having to jump through any hoops. I could add as a third reason, that I paid good money for the RV50 precisely because I hoped to use it as a VPN endpoint (amongst other things). Should have done more research - others be warned. But yes, reluctantly, this now looks like the best option, at least until Sierra Wireless update their firmware with an OpenVPN client from the modern era (hell may well freeze over before that happens, far as I can tell).

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.