--explicit-exit-notify causes peer to exit in --mode p2p

[tct]

I was testing plaisthos' --peer-fingerprint setup and discovered that when either peer uses --explicit-exit-notify and then exits (CTRL-C) this causes the remote peer to also exit on a received signal.

So I tested master using a PSK setup and found the same is true.

The log below is for alice configured to listen, bob connects and then disconnects and sends --explicit-exit-notify, alice exits. If bob does not use --explicit-exit-notify then alice remains running. (This works both ways):

2020-10-13 14:16:26 us=20823 OpenVPN 2.6_git [git:master/2ab0a92442dce1d8] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  2 2020
2020-10-13 14:16:26 us=20839 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
2020-10-13 14:16:26 us=21098 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2020-10-13 14:16:26 us=21303 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
2020-10-13 14:16:26 us=21323 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2020-10-13 14:16:26 us=21351 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-10-13 14:16:26 us=21411 Incoming Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
2020-10-13 14:16:26 us=21427 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.6.
2020-10-13 14:16:26 us=21440 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-10-13 14:16:26 us=23635 TUN/TAP device tun34571 opened
2020-10-13 14:16:26 us=23676 do_ifconfig, ipv4=1, ipv6=0
2020-10-13 14:16:26 us=23692 /sbin/ip link set dev tun34571 up mtu 1500
2020-10-13 14:16:26 us=28715 /sbin/ip link set dev tun34571 up
2020-10-13 14:16:26 us=31141 /sbin/ip addr add dev tun34571 local 10.127.121.1 peer 10.127.121.2
2020-10-13 14:16:26 us=33588 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:393 ET:0 EL:3 ]
2020-10-13 14:16:26 us=33639 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto UDPv4,ifconfig 10.127.121.2 10.127.121.1,cipher BF-CBC,auth SHA1,keysize 128,secret'
2020-10-13 14:16:26 us=33652 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto UDPv4,ifconfig 10.127.121.1 10.127.121.2,cipher BF-CBC,auth SHA1,keysize 128,secret'
2020-10-13 14:16:26 us=33665 Could not determine IPv4/IPv6 protocol. Using AF_INET
2020-10-13 14:16:26 us=33690 Socket Buffers: R=[212992->212992] S=[212992->212992]
2020-10-13 14:16:26 us=33712 UDPv4 link local (bound): [AF_INET]10.10.101.101:34571
2020-10-13 14:16:26 us=33723 UDPv4 link remote: [AF_UNSPEC]
rrR2020-10-13 14:16:30 us=232388 Peer Connection Initiated with [AF_INET]10.10.201.226:58854
W2020-10-13 14:16:31 us=372858 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-10-13 14:16:31 us=372969 Initialization Sequence Completed
R2020-10-13 14:16:36 us=202181 TCP/UDP: Closing socket
2020-10-13 14:16:36 us=202297 Closing TUN/TAP interface
2020-10-13 14:16:36 us=202346 /sbin/ip addr del dev tun34571 local 10.127.121.1 peer 10.127.121.2
2020-10-13 14:16:36 us=234697 SIGTERM[soft,remote-exit] received, process exiting

[tct]

Built master from today on both server and client and this is still true:

2020-10-13 18:39:08 us=860796 OpenVPN 2.6_git [git:master/a4eeef17b20541a7] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 13 2020

[Gert Döring]

Not sure I fully understand what you are doing. Is this a pure p2p setup? With TLS?

(Not sure we care much about mode p2p together with "some options that make more sense for client/server mode"... we could disallow --explicit-exit-notify in p2p mode...)

[tct]

I was using simple --mode p2p on git/master/openvpn not plaisthos' --peer-fingerprint build. (I found it on plaisthos' build but fully tested on master)

Dazo mentioned that this behaviour may be by design (but not documented) for this mode.

[Gert Döring]

Since nothing has happened here, try to find wisdom on the mailing list...

​https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25254.html

[Gert Döring]

commit d468dff7bdfd79059818c190ddf41b125bb658de
Author: Arne Schwabe <arne@…>
Date: Sun Oct 16 17:49:53 2022 +0200

Change exit signal in P2P to be a SIGUSR1 and delayed CC exit in P2MP

From the implemention of explicit-notify and the fact that it is a an
OCC message (basically the rudimentary predecessor to control channel),
this message is very old.

fixed in master and 2.6.0-to-come.