#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
Owner: | set to David Sommerseth |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
comment:3 Changed 7 years ago by
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
Version: | 2.4_alpha2 → 2.4.0 |
---|
comment:5 Changed 7 years ago by
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
Status: | assigned → accepted |
---|
comment:7 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
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@…
Sent a proposed fix to the mailing list:
https://sourceforge.net/p/openvpn/mailman/message/35573412/