====== OpenVPN ======
====== Installation ======
* Put client configuration into ''/etc/openvpn/client/''
* Start openvpn services
systemctl start openvpn-client@config-name
systemctl status openvpn-client@config-name
systemctl enable openvpn-client@config-name
NOTE: `openvpn-client@` service doesn't contain `restart`.
The result of failed openvpn daemon looks like:
systemctl status openvpn-client@config-name
...
Active: activating (auto-restart) since Mon 2020-10-19 15:50:36 CEST; 15s ago
Docs: man:openvpn(8)
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
https://community.openvpn.net/openvpn/wiki/HOWTO
Main PID: 19630 (code=exited, status=0/SUCCESS)
...
To make sure your VPN is running:
systemctl edit openvpn-client@config-name
and enter following config:
[Service]
Restart=always
RestartSec=300
systemctl daemon-reload
===== issue =====
openvpn[281925]: Failed to query password: Timer expired
openvpn[281924]: ERROR: Failed retrieving username or password
Solution:
[Service]
ExecStart=
ExecStart=/usr/sbin/openvpn --suppress-timestamps --askpass --nobind --config
%i.conf
===== Deprecated =====
* Put client configuration into /etc/openvpn/client.conf
* Enable autostart ALL or specified configs in ''/etc/default/openvpn''
* Generate systemd services from openvon configs systemctl daemon-reload
* Start openvpn services systemct start openvpn
====== Certifcates ======
* CA has to be with X509v3 Key Usage: Certificate Sign, CRL Sign
. Without ''CRL Sign'' latest version of OpenVPN doesn't allow to use CRL.
* basicConstraints = CA:TRUE (critical)
* nsCertType = sslCA # restrict the usage
* keyUsage = keyCertSign, cRLSign
* subjectKeyIdentifier = hash
* authorityKeyIdentifier = keyid:always,issuer:always
* OpenVPN Server
* basicConstraints = CA:FALSE
* subjectKeyIdentifier = hash
* authorityKeyIdentifier = keyid,issuer
* nsCertType = server # restrict the usage
* keyUsage = digitalSignature, keyEncipherment
* extendedKeyUsage = serverAuth # restrict the usage
* OpenVPN Client
* basicConstraints = CA:FALSE
* subjectKeyIdentifier = hash
* authorityKeyIdentifier = keyid,issuer
* nsCertType = client # restrict the usage
* keyUsage = digitalSignature # restrict the usage
* extendedKeyUsage = clientAuth
====== Configuration ======
=== Routing ===
**route** directive adds normal routes to the Kernel table. It routes the packet from kernel to OpenVPN.
**iroute** directive adds routes to internal OpenVPN table. It routes the packets to specified clients.
== Subnets behind client ==
In normal scenario, each VPN client is the final endpoint. But sometimes, there are additional networks behind client.
* Client side (or CCD directory - per client). There are networks **192.168.22.0/24** and **fcaa::/64** behind client:
iroute 192.168.22.0/24
iroute-ipv6 fcaa::/64
* Server configuration
route 192.168.22.0/24
route-ipv6 fcaa::/64
=== Username support ===
To easily distinguish clients with the same cert.\\
**Server configuration**\\
#!/bin/sh
exit 0
duplicate-cn
auth-user-pass-verify /etc/openvpn/auth-accept.sh via-env
auth-user-pass-optional
#username-as-common-name
**Client configuration**\\
Create file with username in 1st line, and password in 2nd
client_A
fakepassword
auth-user-pass /etc/openvpn/devicename
===== IPv6 =====
* [[https://community.openvpn.net/openvpn/wiki/IPv6]]
* [[http://silmor.de/ipv6.openvpn.php]]
* [[https://superuser.com/questions/1151539/routing-problems-with-ipv6-over-openvpn]]
* [[https://www.digitalocean.com/community/questions/openvpn-ipv6-works-only-in-local-network]]
====== Troubleshooting ======
**Error**: "write to TUN/TAP : Invalid argument (code=22)".\\
**Cause**: one side use LZO compression, second side not.\\
**Solution**: "comp-lzo no" on both sides.\\
**Note**: \\
//this is a bug: the server pushes out 'comp-lzo' to the client but this is not picked up, because the client does not have 'comp-lzo' configured in the client config (all according to man page). The bug is , that when the client reconnects that it then does honor the 'comp-lzo' pushed out from the server. The client should either consistently refuse 'comp-lzo' or it should consistently accept this option as pushed out by the server.
//
**Error**: Cannot open TUN/TAP dev /dev/net/tun: Permission denied (errno=13).\\
Exiting due to fatal error\\
Use persist-key and persist-tun.
**Cause**: on VPS platform /dev/net/tun has only root permisstion. So openvpn should be started as root user.
**Error**: unsupported protocol
**Cause**: Modern OpenSSL (like 1.1.1) config forbids TLSv1
**Solution**:
MinProtocol = TLSv1
**Error**: File transfer stuck
**Cause**: File transfer are using maximum packet size, which probably cannot fit to MTU limitataions
**Solution**: Not tested, try params like:
# On one side of connection
mssfix 1400
# MTU on tunX interface
# has to be set on both sides
tun-mtu 1400
More:
* [[https://community.openvpn.net/openvpn/wiki/271-i-can-ping-through-the-tunnel-but-any-real-work-causes-it-to-lock-up-is-this-an-mtu-problem]]
* [[https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn|Setting correct MTU for OpenVPN]]
====== rsyslog ======
if $programname startswith 'ovpn-' then /var/log/openvpn/ovpn.log
& ~
mkdir /var/log/openvpn
chown syslog /var/log/openvpv
/var/log/openvpn/*.log {
weekly
size 100M
rotate 4
compress
delaycompress
missingok
notifempty
create 640 syslog adm
}
====== Create p12 package for android ======
openssl pkcs12 -export -in user.crt -inkey user.key -certfile ca.crt -name user -out user.p12