While it looks hackish, I don't think there's a better way (in Bash) to open
the /dev/net/tun character device.
Checking for presence of /dev/net/tun like were doing is not good enough.
nf_tables is not available in old OpenVZ kernels, so we need to use
iptables-legacy instead.
This issue only affects Debian 10 as it is the only distribution using iptables
with a nf_tables backend by default.
This is supposedly resolved in the newest kernels: https://bit.ly/3fgNZCh
Additionally, a bugfix for the ip6tables path is also included.
The new systemd service at `/usr/lib/systemd/system/openvpn-server@.service` that comes with openvpn 2.4 includes the status option in `ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf`
Using this default allows to have multiple servers with their own status files and all in the same log directory. Example `/run/openvpn-server/status-server.log` `/run/openvpn-server/status-server2.log`
New logic makes way more sense:
- If either firewalld or iptables are present, use whatever we have
- If not, install firewalld in CentOS/Fedora and iptables in Debian/Ubuntu
- Use a checkip service which works fine over HTTP to avoid issues in systems
where ca-certificates is not available
- Increase timeout to 10 seconds, because the new service is a bit slower from
some locations
- Improve grep sanitization
- Fix#694: added sanitization during the public IP address configuration and
switch to AWS checkip since the Akamai service doesn't support HTTPS.
- Add validation to cover an unlikely case where: server is behind NAT,
checkip service is unreachable and user doesn't provide input when asked for
the public IP address or hostname.
- Other small improvements not worth describing in detail.
LowEndSpirit fixed the issue on their end, so this is longer needed.
Additionally, the check causes unneeded trouble for users whose system doesn't
have the iptables package installed.
This commit contains lots changes which are not very significant on its own but
provide important usability improvements and future proofing.
It also includes changes which required OpenVPN v2.4+ and were pending until
that version became widely available.
- General cleanup
- Improved IP address and NAT configuration
- Added input validation and sanitization
- Fix#603
- Remove "sndbuf" and "recvbuf" parameters
- Add server-side "explicit-exit-notify"
- Switch from "setenv opt" to "ignore-unknown-option"
- Switch from "tls-auth" to "tls-crypt"
- Other minor bugfixes and optimizations
OpenVPN 2.4 packages provide a new systemd service unit which uses a different
directory structure. This commit drops support for Ubuntu 16.04 which has v2.3
packages.
- SELinux in CentOS already has rules for both udp/1194 and tcp/1194,
so the protocol check was not needed.
- Remove unneeded arguments from some grep and rm commands.
Cleaner and better:
- Not relying in an external service
- Avoids a false positive when the server has multiple public IPv4
addresses and the user selects one which is not the default gateway
curl is always included with CentOS and wget is always included with
Debian/Ubuntu. So it was useless to install wget in CentOS like we were
doing for those cases when it wasn't already installed. Now curl will
be used instead.
Added 1.1.1.1 and removed two mostly unpopular choices.
Currently discarded services are: Yandex, Neustar, NTT, HE, Quad9 and
Freenom World. The list was starting to get too big.
Set EASYRSA_CRL_DAYS to 3650 instead of the default 180.
OpenVPN 2.4+ enforces the nextUpdate value in the CRL as a hard limit,
and will not work if more than 6 months passed since it was generated.
- Removed Debian 9 compatibility warning
- openvpn-blacklist is no longer uninstalled on removal
- Improvement: removal of /usr/share/doc/openvpn* hasn't been needed
for years
- Fixed: live iptables removal was failing for Debian since
6d51476047
This was long overdue for compatibility reasons. My decision to force
the upgrade now, has been made following recomendations published in
the OpenVPN 2.4 audit performed by Cryptography Engineering LLC.
- When FirewallD is detected, NAT is now applied via FirewallD instead
of iptables (fixes#267).
- iptables REJECT/DROP/ACCEPT rules where not being properly detected.
- iptables rules were applied even when FirewallD was detected and the
same rules were being applied via firewall-cmd.
- This will generate a warning in unsupported environments.
- This will not work if the client is using an OpenVPN version lower
than 2.3.9
- For OpenVPN 2.3.3+, ignore-unknown-option could be used instead of
setenv opt to prevent a warning.
TL;DR: upgrade to the latest OpenVPN on Windows, ignore the warning
elsewhere.
Thanks a lot for your continuous work on OpenVPN, @ValdikSS.
