Hi, bad news...
On Thu, Dec 01, 2022 at 12:01:28PM +0100, Arne Schwabe wrote:
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index 1b418b1bc..958bf0b56 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1174,9 +1174,22 @@ process_incoming_dco(struct context *c)
>
> dco_do_read(dco);
>
> + /* FreeBSD currently sends us removal notifcation with the old peer-id in
> + * p2p mode with the ping timeout reason, so ignore that one to not shout
> + * ourselves in the foot and removing the just established session */
> + if (dco->dco_message_peer_id != c->c2.tls_multi->dco_peer_id)
> + {
> + msg(D_DCO_DEBUG, "%s: received message for mismatching peer-id %d, "
> + "expected %d", __func__, dco->dco_message_peer_id,
> + c->c2.tls_multi->dco_peer_id);
> + return;
> + }
This code works perfectly well for p2p TLS environments, but makes OpenVPN
explode in a scenario that my tests did not trigger properly
- you have a p2p tun instance with --secret & DCO
- you have a second p2p DCO instance on the same machine, with TLS
- peers connect and disconnect to the p2p TLS instance
- the *first* instance receives a DCO message, and explodes...
2022-12-07 08:34:50 us=63605 setsockopt(IPV6_V6ONLY=0)
2022-12-07 08:34:50 us=63826 UDPv6 link local (bound): [AF_INET6][undef]:51204
2022-12-07 08:34:50 us=64015 UDPv6 link remote: [AF_UNSPEC]
2022-12-07 08:35:00 us=977186 Attempting to send data packet while data channel
offload is in use. Dropping packet
Program received signal SIGSEGV, Segmentation fault.
0x00005555555772b9 in process_incoming_dco (c=0x7fffffffd460) at forward.c:1180
1180 if (dco->dco_message_peer_id != c->c2.tls_multi->dco_peer_id)
(gdb) where
#0 0x00005555555772b9 in process_incoming_dco (c=0x7fffffffd460)
at forward.c:1180
#1 process_io (c=0x7fffffffd460) at forward.c:2283
#2 0x000055555559db4c in tunnel_point_to_point (c=0x7fffffffd460)
at openvpn.c:94
#3 openvpn_main (argc=2, argv=0x7fffffffe608) at openvpn.c:311
#4 0x00007ffff7cbf083 in __libc_start_main (main=0x55555555e500 <main>,
argc=2, argv=0x7fffffffe608, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe5f8)
at ../csu/libc-start.c:308
#5 0x000055555555e53e in _start () at socket.h:1206
(gdb) print *dco
$2 = {nl_sock = 0x555555642bd0, nl_cb = 0x55555563b310, status = 0,
ifmode = __OVPN_MODE_FIRST, ovpn_dco_id = 37, ovpn_dco_mcast_id = 5,
ifindex = 27659, dco_packet_in = {capacity = 65536, offset = 0, len = 0,
data = 0x555555643370 ""}, dco_message_type = 0, dco_message_peer_id = -1,
dco_del_peer_reason = 0}
(gdb) print c->c2.tls_multi
$3 = (struct tls_multi *) 0x0
^^^^ dat.
Bäm.
My tests did not alert me of this, as the sequence of things is
- build new openvpn binary
- stop all instances
- start all instances with new binary
- run client side tests against all these instances
- be happy if client side tests succeed
the client side tests tested p2p udp (8) before p2p udp TLS (11), so
never noticed that after running (11), (8) would not work any longer...
One item of obvious confusion - yes, this is --secret and not TLS, and
yes, we use DCO...
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
