Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#801 closed Bug / Defect (fixed)

static key tunnels impossible to start via systemd

Reported by: grawity Owned by: David Sommerseth
Priority: major Milestone: release 2.4.1
Component: Packaging Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: systemd
Cc:

Description

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...)

Change History (7)

comment:1 Changed 4 years ago by Gert Döring

Owner: set to David Sommerseth
Status: newassigned

comment:2 Changed 4 years ago by eworm

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

comment:3 Changed 4 years ago by 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@.)

comment:4 Changed 4 years ago by Samuli Seppänen

Version: 2.4_alpha22.4.0

comment:5 Changed 4 years ago by David Sommerseth

Keywords: systemd added
Milestone: release 2.4.1

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

comment:6 Changed 4 years ago by David Sommerseth

Status: assignedaccepted

comment:7 Changed 4 years ago by David Sommerseth

Resolution: fixed
Status: acceptedclosed

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I took the liberty to improve the commit message a little bit,
to make a few things clearer.

Your patch has been applied to the following branches

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 <davids@openvpn.net>
     Acked-by: Gert Doering <gert@greenie.muc.de>
     Acked-by: Christian Hesse <mail@eworm.de>
     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 <davids@openvpn.net>


- --
kind regards,

David Sommerseth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYiPJxAAoJEIbPlEyWcf3yxH4QALLTpJeE7AYS5N+54cRbswIM
Qjw/rKIU5WUe7hf6R//H8HmsWWbhCddYMYojl1XRcLglUdGFm+fTWkTUIUAtEZIy
F9IeTQNVRBYKXoJ5pVWs+9MfCKrdP7tuaUOouqmpuaU3EUwOTwXb9jfDhdNmiQFP
bbE3LC5uv4/BMUK/nPWX/9bqfiUhRRhoOIgDeLBaz2opvBNhLzx4wZV5EPXIsHG0
i1/BKmaU4nlBtVdC0CnL3fuKo1rjoAM+gPqZK1RbZISOBuXXuSJPx9hbNwaY1tU9
Vnvzd4iGmDdjBmxRkjgCwtYcwGGSPR5CCTa0xttqBFAj9Ljp2ZkQECPMWHWbY2D5
3/nj1RhY//YV6iWQD4dgq/Xtnfhp5c9bW00vl8t3h7psiO1BbkrRyQBMvGX7McwS
BvrgXhL0b8E5YLYM45ZQfYeCeNHXlZRlAIVEV0eC6ZHvFKqkVlhsjDHMzwztgbyF
tydEp8vDQtpixIMccUDPtYdWx5OXEje/sR0394tymYwCoMlak4lF4ED2PXdzzkHB
Lf41uTgoGUFhw3qbEaIhhTvbRCYq/AfSi7ojn46zhVqy6YPUG6F5WC4oHRlrvB63
OgGDtN2+F4loKXCOnbMPGM0eT3TKx11ft/fwnCJuVH6RVW3hybanGEXr3wkvWy6C
B/PEIq+CSxztTxxY49OI
=dvhT
-----END PGP SIGNATURE-----

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]

Version 1, edited 4 years ago by David Sommerseth (previous) (next) (diff)
Note: See TracTickets for help on using tickets.