| Prev: VoIP Versus Intrusion Alarm | Next: Transfer a Domain to a New Registrar |
| (Index) |
You upgrade something and your VPN(s) stop working. This is an aide-memoire of issues to check out. I operate both the clients and the server; if you're using a commercial or enterprise VPN service, you pretty much will have to fix it at the client end only.
I've seen quite a number of issues go wrong:
If the server's host certificate changed, the client configuration needs to adapt. OpenVPN (2.4.3) in particular checks by default the server's complete Distinguished Name. See the --verify-x509-name and --x509-username-field options for how to look at the SANs (preferred) or the Common Name.
If the client proffers a X.509 certificate to get service, make sure that it is not expired, that the matching private key is configured, and that the trust chain that signed it is available to the client, which needs to send it to the server. For OpenVPN this would be the --ca or --pkcs12 options. The server will also be configured with the trust chain (CA), possibly more than one of them, that it will believe in for granting service.
On Android, the best way to handle the client cert is to install it in the systemwide certificate storage, and then tell the OpenVPN client to use it from there. My biggest problem with the system cert store is deleting expired or botched certs.
At my house, LTE signal strength is pathetic but the signal strength is good for HSPA and lower (3G and 2G protocols). Therefore I switch between them depending on where I go. LTE supports IPv6 as a mandatory feature, but HSPA doesn't know about IPv6. My server has IP addresses in both families. Normally the client will auto switch, but OpenVPN in particular can get stuck connecting to the IPv6 server.
When OpenVPN uses the TCP-client protocol to an IPv6 server via HSPA,
it gets a no route to host
error code, and fails over to IPv4,
connecting successfully. But for the preferred UDP protocol there is no
error code, and it waits for UDP replies until it times out. Setting the
protocol to udp4 (or tcp4-client) makes it use only that family.
However, NetworkManager does not use a configuration file for OpenVPN; it puts all the parameters on the command line, translating them from its own style of configuration file. So far I haven't found out how to influence it to provide a protocol of udp4.
A convenient way to test VPNs on my laptop goes like this:
Wi-Fi Hotspotfeature (hostapd).
Gotcha: traffic to the wild side goes through the VPN with no problems. But traffic to the local net is blocked. Because there is a route to the local net via the laptop's wlan0 (not the VPN's tun0), which is going to the cellphone, and the local net's firewall blocks traffic from the wild side (the cellphone) unless I use my handy dandy firewall opener (TLS, and authentication is required). So far I haven't automated the mechanism to remove the offending route.
OpenVPN specifically needs a route from the client to the server, not through the VPN, because of a chicken and egg issue: the VPN bearer packets can't go through the VPN which they are bearing. But this means that all traffic to the server's wild side will not go through OpenVPN. One workaround is to send to the server's internal address.
IPSec (StrongSwan) doesn't have this problem because it doesn't really have a tunnel: the individual packets are tagged with a Security Association, and the associated key can decrypt the packets. The packets belong to their own connection, not being encapsulated in a separate bearer or tunnel connection.
| Prev: VoIP Versus Intrusion Alarm | Next: Transfer a Domain to a New Registrar |
| (Index) |