On 19/07/20 9:20 pm, David Sommerseth wrote:
> 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 :)
Thanks for the quick response :-)
> 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.
Accepted.
> 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 lack of client/server relation is what I'm after. I don't want to
impose an artificial precedence between the machines that doesn't really
exist. I chose the client unit because that was recommended in some
readme; I don't remember which.
> 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.
That's what I couldn't manage - a p2p network (no client or server)
using certificates. In the end I concluded it couldn't be done, but I'm
happy to be corrected.
> 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.
I guess I can do that if I have to, but it will mean rather more complex
ansible setup to deploy the right kind of file to the right machine. And
it just feels less 'clean' :-)
> 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>
Thanks for your help :-)
Richard
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
