- Install iptables systemd service for Debian, Ubuntu and CentOS
- Fix iptables install for ArcLinux
- Remove the use rc.local file
- Remove all iptables rules when removing openvpn (cf. #60 )
Revert ad3c223385
On some servers, this prevented OpenVPN to start on boot. (Socket bind failed on local address [AF_INET] IP:1194 Cannot assign requested address)
This seems like a little change but it was not easy to find.
I want this script to support only OpenVPN 2.4 servers, but also 2.4 and 2.3 clients.
The thing is, the OpenVPN 2.3 client doesn't care at all what cipher the server wants to use. The cipher parameter in the client config is the king here.
But with OpenVPN 2.4, you can specify whatever cipher you want, the clients and the server will negotiate the best cipher possible, which is AES-256-GCM right now. The use of --ncp-ciphers cipher_list is useless because a 2.3 client will still use its cipher and a 2.4 client will still use AES-256-GCM.
I won't detail all my experiments here, but in the end, ncp-disable disable the cipher negotiation for 2.4 clients. But it will only work if the cipher in the server config and the client config are the same, and as they are in the script, it's ok. This is not the best solution because that means if you want to support a 2.3 client, you'll be forced to use one and only one AES-CBC cipher, even with your 2.4 clients, even though you could use a different cipher for each client. But as we're still using AES and OpenVPN 2.4 getting more and more deployed, this is not a too big issue in the end. Also adding menus to to choose what kind of client you want etc would make the script pretty complicated, so this is a good compromise here.
TL;DR: ncp-disable enforces a OpenVPN 2.4 client to use the specified cipher in the server and the client config.
See here for me details regarding the data channel cipher negotiation in OpenVPN 2.4 : https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage#lbAJ
From the OpenVPN wiki:
>Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.
>If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.
Tl;DR: if we're using an AEAD cipher (AES GCM), `auth alg` won't have inpact on the impact channel, but only on the control channel if tls-auth/tls-crypt is enabled.
- Add support for AES-GCM ciphers for the data channel
- Add support for tls-crypt
- Add support for ECDSA certificates
- Add support for ECDHE
- Add choice for HMAC auth algorithm
- Add choice for certificate hash algorithm
- Add choice for the control channel's cipher
All these options have an OpenVPN 2.3-compatible choice (example : RSA cert and DH key)
