Opened 7 years ago

Closed 7 years ago

Last modified 7 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 7 years ago by Gert Döring

Owner: set to David Sommerseth
Status: newassigned

comment:2 Changed 7 years ago by eworm

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

comment:3 Changed 7 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 7 years ago by Samuli Seppänen

Version: 2.4_alpha22.4.0

comment:5 Changed 7 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 7 years ago by David Sommerseth

Status: assignedaccepted

comment:7 Changed 7 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

ACK.  Tested this lightly with both server and client profiles,
and this seems to work very well.  Users having keys under
/home will probably complain.  But I do not think system wide
configurations should depend on keys in users' home directories.

Your patch has been applied to the following branches

commit 76096c605fcac4815674b6ae76ac1f31f03a8186  (master)
commit ba3ccaf92d379f8a2efad80cee7dc2806088f421  (release/2.4)
Author: Christian Hesse
Date:   Tue Dec 27 23:18:32 2016 +0100

     systemd: Add more security feature for systemd units

     Signed-off-by: Christian Hesse <mail@eworm.de>
     Acked-by: David Sommerseth <davids@openvpn.net>
     Message-Id: <20161227221832.610-1-list@eworm.de>
     URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13743.html
     Signed-off-by: David Sommerseth <davids@openvpn.net>


- --
kind regards,

David Sommerseth

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

iQIcBAEBAgAGBQJYiPPRAAoJEIbPlEyWcf3ymHAQAIuy8UXELqs4blJCs0IfHtOg
nALf1ALs+fvhQp7he+Z+wxmDT+QFL3mli53RXKZZGG8y+boWgRFkJ11PX4YzsCO9
KSJAWqbDRW+n9pp8uZ7q6D+uLeiO6ziKhEm6Jl2zln4FtTxi3pW8jUcONEdNwBtP
XSzJ7vdKAuiKGp8GvDm+uWpyjRJvpsClKynPvh2sN0bY6ERlkLDYKUMy37+1vDfc
HV6k1Rdwq7L4fVxbx9P6YWF/iKX3yuqTK1Qs99ZaZ7N4UE+QAYtuOtzDbAb+ISrN
fs7kOim2H5OZ8qfgYTosE6bRLP4mTEqgKX7zjYUMPWWZZgvrW3H9E4v/nGWupZxD
NaLIE+WELGDVZRnHMZRkVYCbK6zcPYyvfrehc2O/cKKNAtsIQLDe8NdiirpWsbRB
7+e/UCgIyvtPTxaf1FoVD0ENdyfGXT3EYRIuCsPA6Uk9C5vu3JpAhBnxhleaynE6
Vkh29k3lxBi/CHKsIa2DYYLqumrkwlI9TJ6FHSt7xR4zYkA92BZb2UKZGDkuCss7
g5wNrnxuswIaAgllsa7YSKkVSS41DhlUZG+flFnFLbodME5HatUJWokAqJzOzC7L
vH1SMR+AQGKRwV1YkEJYRsxYfKJFByViipoqHkStq70Bl7Qql2hGXS+qh8cC/bLK
WX35Il88WHshyCmcqI+d
=2/Wt
-----END PGP SIGNATURE-----

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

Version 0, edited 7 years ago by David Sommerseth (next)
Note: See TracTickets for help on using tickets.