--enable-small is incompatible with some VPN providers

[patrakov]

Some embedded firmwares (e.g. OpenWRT) compile their OpenVPN with the --enable-small configure option. However, OpenVPN compiled with this option fails to connect to several public VPN providers, including vpngate.net. This should either be fixed or this incompatibility must be documented (so that these firmwares stop using this option).

Steps to reproduce:

Compile OpenVPN with --enable-small

Go to ​http://www.vpngate.net/en/ , download any config file that uses UDP.

Run openvpn --config that_file.ovpn

Result:

./src/openvpn/openvpn --config /home/aep/vpngate_vpn200520198.opengw.net_udp_1491.ovpn
Sun Nov  2 19:04:43 2014 OpenVPN 2.3.5 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov  2 2014
Sun Nov  2 19:04:43 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Sun Nov  2 19:04:43 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sun Nov  2 19:04:43 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sun Nov  2 19:04:44 2014 UDPv4 link local: [undef]
Sun Nov  2 19:04:44 2014 UDPv4 link remote: [AF_INET]79.136.88.104:1491
Sun Nov  2 19:04:44 2014 TLS: Initial packet from [AF_INET]79.136.88.104:1491, sid=1f172fe0 8a34fde5
Sun Nov  2 19:04:44 2014 VERIFY OK: depth=0, CN=fr2hjt3x4xqbfw.jp, O=gxy2m w0dyn56h2, C=US
Sun Nov  2 19:04:44 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Nov  2 19:04:44 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov  2 19:04:44 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Nov  2 19:04:44 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov  2 19:04:44 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sun Nov  2 19:04:44 2014 [fr2hjt3x4xqbfw.jp] Peer Connection Initiated with [AF_INET]79.136.88.104:1491
Sun Nov  2 19:04:46 2014 SENT CONTROL [fr2hjt3x4xqbfw.jp]: 'PUSH_REQUEST' (status=1)
Sun Nov  2 19:04:46 2014 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10'
Sun Nov  2 19:04:46 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov  2 19:04:46 2014 TUN/TAP device tun0 opened
Sun Nov  2 19:04:46 2014 TUN/TAP TX queue length set to 100
Sun Nov  2 19:04:46 2014 Initialization Sequence Completed
Sun Nov  2 19:04:50 2014 write to TUN/TAP : Invalid argument (code=22)
Sun Nov  2 19:04:55 2014 write to TUN/TAP : Invalid argument (code=22)
Sun Nov  2 19:05:00 2014 write to TUN/TAP : Invalid argument (code=22)
Sun Nov  2 19:05:05 2014 write to TUN/TAP : Invalid argument (code=22)

Good log, without --enable-small:

# openvpn --config /home/aep/vpngate_vpn200520198.opengw.net_udp_1491.ovpn
Sun Nov  2 19:07:29 2014 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov  2 2014
Sun Nov  2 19:07:29 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Sun Nov  2 19:07:29 2014 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sun Nov  2 19:07:29 2014 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sun Nov  2 19:07:29 2014 UDPv4 link local: [undef]
Sun Nov  2 19:07:29 2014 UDPv4 link remote: [AF_INET]79.136.88.104:1491
Sun Nov  2 19:07:29 2014 TLS: Initial packet from [AF_INET]79.136.88.104:1491, sid=7d37fb92 4a316f39
Sun Nov  2 19:07:29 2014 VERIFY OK: depth=0, CN=fr2hjt3x4xqbfw.jp, O=gxy2m w0dyn56h2, C=US
Sun Nov  2 19:07:29 2014 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Nov  2 19:07:29 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov  2 19:07:29 2014 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Nov  2 19:07:29 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Nov  2 19:07:29 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sun Nov  2 19:07:29 2014 [fr2hjt3x4xqbfw.jp] Peer Connection Initiated with [AF_INET]79.136.88.104:1491
Sun Nov  2 19:07:32 2014 SENT CONTROL [fr2hjt3x4xqbfw.jp]: 'PUSH_REQUEST' (status=1)
Sun Nov  2 19:07:32 2014 PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.211.1.21 10.211.1.22,dhcp-option DNS 10.211.254.254,dhcp-option DNS 8.8.8.8,route-gateway 10.211.1.22,redirect-gateway def1'
Sun Nov  2 19:07:32 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov  2 19:07:32 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov  2 19:07:32 2014 OPTIONS IMPORT: route options modified
Sun Nov  2 19:07:32 2014 OPTIONS IMPORT: route-related options modified
Sun Nov  2 19:07:32 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov  2 19:07:32 2014 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=br0 HWADDR=94:de:80:6f:9a:d4
Sun Nov  2 19:07:32 2014 TUN/TAP device tun0 opened
Sun Nov  2 19:07:32 2014 TUN/TAP TX queue length set to 100
Sun Nov  2 19:07:32 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sun Nov  2 19:07:32 2014 /bin/ifconfig tun0 10.211.1.21 pointopoint 10.211.1.22 mtu 1500
Sun Nov  2 19:07:32 2014 /bin/route add -net 79.136.88.104 netmask 255.255.255.255 gw 192.168.1.1
Sun Nov  2 19:07:32 2014 /bin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.211.1.22
Sun Nov  2 19:07:32 2014 /bin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.211.1.22
Sun Nov  2 19:07:32 2014 Initialization Sequence Completed

Note the difference in the options being pushed by the server in the PUSH_REPLY message.

[patrakov]

Downstream report in OpenWRT: ​https://dev.openwrt.org/ticket/16898

The issue seems to be with the fact that the OCC code is disabled, and the vpngate.net server relies on it.

[Gert Döring]

I'm not exactly sure why this is a bug on our side - the server fails to push config, and yes, this will make the client not work.

OCC code is not huge, but the point of --enable-small is to reduce binary size by leaving out optional bits - and in a client-server environment where the server is pushing the client config anyway, it's fairly redundant. So OCC qualifies.

Is this vpngate.net only, or others as well? Have you talked to vpngate about this, maybe they can explain what happens and why their side needs OCC to work right.

Stock OpenVPN servers or OpenVPN AS servers (privatetunnel.net, for example) will not cause such issues.

[patrakov]

I have not tried to talk to them. However, the same company also aggressively advertises their SoftEther? VPN product, so other VPN providers using the same product may be affected.

[patrakov]

Reported to SoftEther? VPN authors: ​https://github.com/SoftEtherVPN/SoftEtherVPN/issues/110

[patrakov]

They responded with a long explanation what they do with the option string and why "V0 UNDEF" does not work.

[patrakov]

They worked around the incompatibility, but it seems to me that their opinion is still that the "V0 UNDEF" option string (sent by the --enable-small openvpn) is deficient, because they cannot dynamically select the features offered by their server (e.g. offer tun or tap as the client wants) based on it.

[Gert Döring]

Hi,

thanks for checking with them. This is actually quite interesting, using the OCC data to decide what to push back to the client - it's not the official way to do option negotiation, but you can't actually not see if the client is set to "dev tun" or "dev tap" using the peer-info stuff (only what sort of compression is supported, right now).

OTOH I'd argue for "if the client is not telling you its config, just use a tun config", as all the mobile clients only support tun anyway, and there is not much else that you cannot push to override whatever the client has pre-configured.

In a VPN service provider, the provider should just give the client a config file that does what is needed, not rely on internal protocol details of the OpenVPN protocol to "give the client what it wants"... it's a cool hack, but still, not a documented API so it might change at any time.

[patrakov]

Well, the "mobile clients" argument is somewhat overstretched. Router firmware vendors also compile their OpenVPN with --enable-small, they do support tap, and they are not mobile clients.

But SoftEther? folks have made the default option string configurable, so it doesn't really matter and can indeed express the "assume tun if unknown" policy.

Still, I would like the "interoperability with (old versions of) SoftEther? VPN" issue to be documented somewhere in OpenVPN source (e.g. in the ./configure script output).

[Samuli Seppänen]

I'll close this as "notabug". Any note in the source code about incompatibility with old versions of SoftEther? VPN would be mostly obsolete from the get go, but would still linger in the source code for many years.