static key tunnels impossible to start via systemd

[grawity]

With the new upstream systemd .service units, my static key tunnels are difficult or impossible to manage. The core issue is that OpenVPN now waits for the tunnel to be 'up', which is pretty difficult to achieve given the symmetrical nature of the tunnels:

• Let's say node A boots first; when it tries to start openvpn-server@NodeB.service , it waits a minute for node B and then gives up.
• When node B boots, it similarly waits a minute for node A – but node A has already given up, so eventually node B also fails.
• The only way to start the tunnel is to restart the service at the exact same moment on both nodes.

(I'm using openvpn-server@ on both ends because `openvpn-client@ enforces --nobind, which conflicts with the tunnels' own --lport option.)

(This is technically a report for the 2.4.0 release, but that's not in the version list...)

[eworm]

Sent a proposed fix to the mailing list:
​ https://sourceforge.net/p/openvpn/mailman/message/35573412/

[grawity]

The above patch works for me.

OTOH, I guess other users might actually find the delay useful, but in that case there would need to be a way to choose which side should wait (e.g. there could be a --wait-for-peer option for openvpn-client@.)

[David Sommerseth]

I've just submitted an alternative patch to the mailing list, which might be more easily accepted. It does not have the nicer status message which the patch from eworm have submitted. But that is a completely different issue.

If you have a chance, please test this new patch and report back

​ https://sourceforge.net/p/openvpn/mailman/message/35624370/
Message-Id: <20170124232344.7825-1-davids@…>

Author: David Sommerseth
Date:   Tue Jan 24 23:16:24 2017 +0100

    systemd: Move the READY=1 signalling to an earlier point
    
    Currently, OpenVPN will first tell systemd it is ready once the
    log will be appended with "Initialization Sequence Completed".
    This turns out to cause some issues several places.
    
    First, it adds challenges if --chroot is used in the configuration;
    this we already fixed.  Secondly, it will cause havoc on static key
    p2p mode configurations where the log line above will not happen
    before either sides have completed establishing a connection.  And
    thirdly, if a client configuration fails to establish a connection
    within 90 seconds it will also fail.  For the third case this may
    not need to be a critical issue, as the host just needs to get
    an Internet access established first - which in some scenarios may
    take much longer than those 90 seconds after the OpenVPN client
    configuration tries to start.
    
    The approach this patch takes is to consider OpenVPN ready once
    all the initial preparations and configurations have happened - but
    before a connection to a remote side have been attempted.  This
    also removes the need for specially handling the --chroot scenario.
    
    The final "Initialization Sequence Completed" message update is
    kept (though slightly simplified) to indicate we're in a good
    state - even though that update will still not be visible
    if --chroot is used (as before this patch).
    
    Trac: #827, #801
    Signed-off-by: David Sommerseth

[David Sommerseth]

Patch applied. Closing this, as this should resolve the issue described in the initial description.

commit e83a8684f0a0d944e9d53cdad2b543cfd1b6fbae  (master)
commit 041fd6488434b5df01f86dd873b536a2b690ee13  (release/2.4)
Author: David Sommerseth
Date:   Wed Jan 25 00:23:44 2017 +0100

     systemd: Move the READY=1 signalling to an earlier point

     Trac: #827, #801
     Signed-off-by: David Sommerseth
     Acked-by: Gert Doering
     Acked-by: Christian Hesse
     Message-Id: <20170124232344.7825-1-davids@openvpn.net>
     URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13945.html
     Signed-off-by: David Sommerseth

​ https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13954.html
Message-Id: 20170125185203.10467-1-davids@…

[update: paste the body text from the correct e-mail, the URL was correct though]