diff options
| author | Lev Stipakov | 2023-10-22 10:27:40 +0200 |
|---|---|---|
| committer | Gert Doering | 2023-10-22 10:59:35 +0200 |
| commit | e78f88d8ea113585ca16945ef0361710b838ec7d (patch) | |
| tree | 6b81300e3bf3cee732c5edbf04d347ab6c748456 | |
| parent | 8bbc2926e620bcf995e6697e614a2716b572c07d (diff) | |
| download | openvpn-e78f88d8ea113585ca16945ef0361710b838ec7d.zip openvpn-e78f88d8ea113585ca16945ef0361710b838ec7d.tar.gz | |
dco: warn if DATA_V1 packets are sent to userspace
Servers 2.4.0 - 2.4.4 support peer-id and AEAD ciphers,
but only send DATA_V1 packets. With DCO enabled on the
client, connection is established but not working.
This is because DCO driver(s) are unable to handle
DATA_V1 packets and forwards them to userspace, where
they silently disappear since crypto context is in
DCO and not in userspace.
Starting from 2.4.5 server sends DATA_V2 so problem
doesn't happen.
We cannot switch to non-DCO on the fly, so we log this
and advice user to upgrade the server to 2.4.5 or newer.
Github: fixes OpenVPN/openvpn#422
Change-Id: I8cb2cb083e3cdadf187b7874979d79af3974e759
Signed-off-by: Lev Stipakov <lev@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20231022082751.8868-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg27272.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
(cherry picked from commit df7beea404df48745a608c584d863c5a377b7a1e)
| -rw-r--r-- | src/openvpn/forward.c | 19 |
1 files changed, 18 insertions, 1 deletions
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index d8ad0d1..2510410 100644 --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -1047,6 +1047,24 @@ process_incoming_link_part1(struct context *c, struct link_socket_info *lsi, boo if (c->c2.tls_multi) { + uint8_t opcode = *BPTR(&c->c2.buf) >> P_OPCODE_SHIFT; + + /* + * If DCO is enabled, the kernel drivers require that the + * other end only sends P_DATA_V2 packets. V1 are unknown + * to kernel and passed to userland, but we cannot handle them + * either because crypto context is missing - so drop the packet. + * + * This can only happen with particular old (2.4.0-2.4.4) servers. + */ + if ((opcode == P_DATA_V1) && dco_enabled(&c->options)) + { + msg(D_LINK_ERRORS, + "Data Channel Offload doesn't support DATA_V1 packets. " + "Upgrade your server to 2.4.5 or newer."); + c->c2.buf.len = 0; + } + /* * If tls_pre_decrypt returns true, it means the incoming * packet was a good TLS control channel packet. If so, TLS code @@ -1057,7 +1075,6 @@ process_incoming_link_part1(struct context *c, struct link_socket_info *lsi, boo * will load crypto_options with the correct encryption key * and return false. */ - uint8_t opcode = *BPTR(&c->c2.buf) >> P_OPCODE_SHIFT; if (tls_pre_decrypt(c->c2.tls_multi, &c->c2.from, &c->c2.buf, &co, floated, &ad_start)) { |