Edit: As a test, I have completely disabled IPv6 on the server (ipv6.disable=1 kernel param), and the log reflects this:
Code: Select all
Aug 26 15:31:55 cloud ovpn-server[659]: MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
Code: Select all
Aug 26 15:31:55 cloud ovpn-server[659]: MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
With this version of openvpn:etaoin wrote:Sierra Wireless AirLink RV50 3G/4G router
Code: Select all
RV50 openvpn-1[8692] NOTE: OpenVPN 2.1
With this version of openvpn:etaoin wrote:my OpenVPN server
Code: Select all
OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
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 wrote:
- There has been a huge amount of development in openvpn in the last five years ..
You must upgrade your router.
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.etaoin wrote: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.
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.TinCanTech wrote: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.
Code: Select all
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)
It is not secure by current standards.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
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 wrote:I see a warning in the server log about "IP packet with unknown IP version=0 seen"
Not an option that I am aware of ..etaoin wrote: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,
and what about actual data .. which is transmitted over the same channel as the ping .. ?etaoin wrote:two, I simply disable pings from the client (by setting "Ping interval" to zero) and work around their absence
Agreed.TinCanTech wrote: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.
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).TinCanTech wrote:Use the router as a simple router and have a client inside the LAN provide the VPN end point.
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.etaoin wrote: ↑Sat Aug 26, 2017 7:18 pmI'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).TinCanTech wrote:Use the router as a simple router and have a client inside the LAN provide the VPN end point.