Error on client built with --disable-lzo: write to TUN/TAP : Unknown error (fd=-1,code=122)

[kitsune1]

Connection stays up but no traffic seems to flow.

Server: 2.4.4-2ubuntu1.5
Windows 10 Client: 2.6 master built with --disable-lzo --disable-lz4

Sever pushes compress-stub-v2 if it reports IV_COMP_STUBv2 (and compress lzo to older clients).

PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.178.11.1,topology subnet,ping 30,ping-restart 180,compress stub-v2, route xxx 255.255.255.255,route xxx 255.255.255.255,dhcp-option DOMAIN xxx,dhcp-option DNS xxx,dhcp-option DNS xxx,register-dns,ifconfig 10.178.11.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'

openvpn.exe --version reports

OpenVPN 2.6_git x86_64-w64-mingw32 [SSL (OpenSSL)] [PKCS11] [AEAD] built on May 25 2021
library versions: OpenSSL 1.1.1j  16 Feb 2021
Windows version 10.0 (Windows 10 or greater) 64bit
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_debug=yes enable_dlopen=unknown 
enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no 
enable_libtool_lock=yes enable_lz4=no enable_lzo=no enable_management=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes 
enable_plugin_auth_pam=no enable_plugin_down_root=no enable_plugins=yes 
enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=yes enable_small=no enable_static=yes 
enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=no
 with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_special_build= with_sysroot=no

[kitsune1]

Correction: the PUSH reply above was mistakenly copied from a working connection (on client built with lzo). The correct one is

PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.178.11.1,topology subnet,ping 30,ping-restart 180,route xxx 255.255.255.255,route xxx 255.255.255.255,dhcp-option DOMAIN xxx,dhcp-option DNS xxx,dhcp-option DNS xxx,register-dns,ifconfig 10.178.11.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'

So "compress stub-v2" is not pushed to this client which happens when the client doesn't announce IV_COMP_STUB_v2.

[stipa]

I cannot reproduce this (server 2.4.7, client 2.6 master). Could you provide the relevant part of server config?

[kitsune1]

First, apologies for the noise.

Turns out to be a server config error exposed by this client with no compression support. The details may still interest some, so here is what happened.

The server has a client-connect script to generate some config directives like

if [ -z ${IV_COMP_STUBv2} ]; then
   compress lzo  # legacy clients have comp-lzo in them 
else
   compress stub-v2
   push "compress stub-v2"
fi

My new 2.6 client built with --disable-lzo reports no support for IV_COMP_STUBv2 and gets no compress option pushed. But the server side of the connection gets compress lzo as per the above logic which is wrong. The server's client-connect script needs some rework.

I do not understand why this leads to a TUN/TAP write error.

Please close the ticket.

[Gert Döring]

I think we do now understand why this leads to a TUN/TAP error (we discussed this on IRC).

What happens is that server and client disagree on whether compression is in use.

So the server sends a packet that is compressed, and the client expects an uncompressed packet (this matches my test set up where I experienced a similar thing - I had "allow-compression no" defaults, and the server assumed "if no IV_ thing is sent, it must be a very old client, so, use lzo").

The *client* is very dumb:

• receive a packet from the UDP socket
• decrypt & verify HMAC
• (decompress)
• stuff the encapsulated packet into tun/tap adapter

now, if the "decompress" step fails, you get a decompression error (= server sending uncompressed, client expecting compressed).

But in our scenario, the client will not look at the "inner" packet after decryption + HMAC check, just stuff it into the tun/tap adapter. That one seems to have an "is this a valid IP packet?" check - on Windows, in NDIS path, outside our control - which it isn't, because the first byte is the decompression opcode...

So the errors we see in the log is "incoming packets from server can not be stuffed into tun/tap adapter".

Not sure if we can do anything to actually fix this, except abandon compression completely :-) - the compression framing is what it is. We could have some heuristics inside OpenVPN that says "mmmh, this incoming packet really does not look like IPv4/IPv6, maybe compressed?"... which might actually work reasonably well...

Let's leave this open, if someone wants to have a stab at it.

[Gert Döring]

So I bumped into the same issue today on a p2p misconfiguration - side A having comp-lzo, side B having no compression. This led to side B stuffing compressed packets into the tun interface, creating the same error messages...

Since nobody is working on it, and 2.6 release is coming up, I'm removing the 2.6 milestone - maybe in the pre 2.7 timeframe.