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.

I think in the past this feature fit nicely to the weird inetd + openvpn
mode that seems to have far to many hacks still left in our code. With
inetd, it made sense that the server instance quits if you press C-c
on the client.

In our current state where inetd is no longer supported, this behaviour
to exit makes little sense and this patch changes the behaviour to SIGUSR1.

Testing this lead to a confused v2 of the patch and also finally the
insight that if a CC channel exit is triggered too early the remaining
control channel packets coming in after that can trigger the HMAC code
to open a sessions again if the whole session lasted less than two
minutes (with default settings).

Patch v2: use different signals for p2mp and p2p
Patch v3: use delayed exit for P2MP/CC exit and USR1 for everything else

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20221016154953.2483509-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25403.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>

diff --git a/Changes.rst b/Changes.rst
index df56f76ae11a409d27b354f39dfec898cb135d2e..dfe5bf08003751f8e7bcb4966d151e8e7d129fc3 100644 (file)
--- a/Changes.rst
+++ b/Changes.rst
@@ -163,6 +163,13 @@ User-visible Changes
 - :code:`link_mtu` parameter is removed from environment or replaced with 0 when scripts are
   called with parameters. This parameter is unreliable and no longer internally calculated.
 
+- In point-to-point OpenVPN setups (no ``--server``), using
+  ``--explict-exit-notiy`` on one end would terminate the other side at
+  session end.  This is considered a no longer useful default and has
+  been changed to "restart on reception of explicit-exit-notify message".
+  If the old behaviour is still desired, ``--remap-usr1 SIGTERM`` can be used.
+
+
 Overview of changes in 2.5
 ==========================
 

diff --git a/src/openvpn/occ.c b/src/openvpn/occ.c
index 1ed0d37713e4fc717c1b508b2ed2d895dafe4c85..eb1f2fae763fdc579e3b5553a0aab9bdef1f878c 100644 (file)
--- a/src/openvpn/occ.c
+++ b/src/openvpn/occ.c
@@ -431,7 +431,7 @@ process_received_occ_msg(struct context *c)
 
         case OCC_EXIT:
             dmsg(D_PACKET_CONTENT, "RECEIVED OCC_EXIT");
-            c->sig->signal_received = SIGTERM;
+            c->sig->signal_received = SIGUSR1;
             c->sig->signal_text = "remote-exit";
             break;
     }

diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 26259c6b8d7c516e40dfef1a677cedce9d92ec3f..1bad00605a35531ed431570de4373861f8812632 100644 (file)
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -193,7 +193,25 @@ void
 receive_exit_message(struct context *c)
 {
     dmsg(D_STREAM_ERRORS, "Exit message received by peer");
-    c->sig->signal_received = SIGTERM;
+    /* With control channel exit notification, we want to give the session
+     * enough time to handle retransmits and acknowledgment, so that eventual
+     * retries from the client to resend the exit or ACKs will not trigger
+     * a new session (we already forgot the session but the packet's HMAC
+     * is still valid).  This could happen for the entire period that the
+     * HMAC timeslot is still valid, but waiting five seconds here does not
+     * hurt much, takes care of the retransmits, and is easier code-wise.
+     *
+     * This does not affect OCC exit since the HMAC session code will
+     * ignore DATA packets
+     * */
+    if (c->options.mode == MODE_SERVER)
+    {
+        schedule_exit(c, c->options.scheduled_exit_interval, SIGTERM);
+    }
+    else
+    {
+        c->sig->signal_received = SIGUSR1;
+    }
     c->sig->signal_text = "remote-exit";
 #ifdef ENABLE_MANAGEMENT
     if (management)