On 19/07/2020 07:09, Richard Hector wrote: > Hi all, > > I have 4 machines (actually VPSes) that have a full mesh of VPNs between > them. I'm using a slightly-modified version of the 'client' example > config. Since it appears TLS, and the use of certificates, requires > named client and server peers, I'm using a PSK (one for the whole set). > > This, when it works, seems to work fine. > > The trouble occurs when trying to (re)start the services with systemd. > Using 'systemctl restart openvpn-client@host1', for example, will > sometimes hang, and eventually return when I run the corresponding > command on host1 - but that one then hangs, till I run it on the first > one again ... and so on indefinitely. I can usually make it work if I > stop both, then start both. But arranging timimg like that is difficult, > if one machine needs to reboot - whether the VPN between them will come > back is unpredictable, to say the least. > > On the other hand, the VPNs I have with a more conventional cert-based, > client-server setup cope with reboots at either end just fine. > > Any suggestions on why this happens - what state the peers go into, for > example - and how to avoid it would be gratefully received.
Hi Richard,
As I'm the one who introduced the openpn-{client,server}.service files, I feel
obliged to answer here :)
First of all, the static key p2p mode (using --secret with a preshared key on
both sides) is really not recommended. It's fine for testing a VPN setup for
a short while, but not recommended for production environments - as it does
not give you any forward secrecy (PFS [1]) at all. This means it is possible
to bruteforce the encryption on encrypted data traffic which has been
collected. An successful attack results in all prior and future tunnel
traffic is considered compromised.
This is also why I never really considered the static key p2p mode when
implementing these new unit files. The advantage of these unit files are
essentially that they add more hardening outside of OpenVPN as well and the
server side will automatically restart if the openvpn process suddenly dies.
Also consider that the static key p2p does not really have a client/server
relation. They are both equal nodes which configures "my end point" and "the
remote end point", reflected in the --ifconfig where the IP addresses are
reversed on the hosts. That said, you might have better luck using the
openvpn-server@.service unit files on both sides.
The p2p mode, however, is useful, and often enough for many use cases. But I
do recommend you to use a p2p using a PKI setup. This gives the p2p network
configuration simplicity and adds the PFS aspect. All you need to do here is
to create your own CA (using easy-rsa[2,3]) and create a client and server key
and certificates.
On one side (I'll probably recommend the node with 10.111.111.41) designate
this as the server, by adding --tls-server to the configuration, as well as
adding --ca, --cert, --key and --dh (generated using 'openssl dhparam' with at
least 2048 bits). This side should use the openvpn-server@.service unit file.
The other will be the client side, and needs a copy of the same CA certificate
and its own client key and certificate. The configuration file needs to be
extended with --ca, cert and --key (no --dh). This side can now use the
openvpn-client@.service unit file.
With this slightly changed configuration you keep your network configuration
but enhances the security and this should work fine with the existing unit
files.
[1] <https://en.wikipedia.org/wiki/Forward_secrecy>
[2] <https://github.com/OpenVPN/easy-rsa/>
[3] <https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md>
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
