OpenVPN client drops after assigning interface

[mgi]

Hello,

Still fighting with client OVPN connection on pfSense/Netgate.

I have (I believe) a quite simple client configuration.

dev ovpnc2
verb 3
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 10.10.10.254
tls-client
client
lport 0
management /var/etc/openvpn/client2/sock unix
remote OVPN_SERVER_FQDN 1194 udp4
auth-user-pass /var/etc/openvpn/client2/up
auth-retry nointeract
route 10.0.0.0 255.0.0.0
…
capath /var/etc/openvpn/client2/ca
cert /var/etc/openvpn/client2/cert 
key /var/etc/openvpn/client2/key 
tls-auth /var/etc/openvpn/client2/tls-auth 1
data-ciphers AES-128-CBC:AES-128-GCM:AES-192-CBC:AES-192-GCM:AES-256-CBC:AES-256-GCM
data-ciphers-fallback AES-128-GCM
allow-compression asym
resolv-retry infinite
comp-lzo no
route-nopull

After I assign the ovpnc2 port to an interface, the connection stops working (nothing in the log), and I can see that all routes disappear.

Then, when I try to restart the connection under Status / OpenVPN, I just get TLS errors in the log.

Apr  2 19:04:14 pfSense openvpn[2402]: SIGUSR1[soft,tls-error] received, process restarting
Apr  2 19:04:24 pfSense openvpn[2402]: VERIFY KU ERROR
Apr  2 19:04:24 pfSense openvpn[2402]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr  2 19:04:24 pfSense openvpn[2402]: TLS_ERROR: BIO read tls_read_plaintext error
Apr  2 19:04:24 pfSense openvpn[2402]: TLS Error: TLS object -> incoming plaintext read error
Apr  2 19:04:24 pfSense openvpn[2402]: TLS Error: TLS handshake failed

To fix the errors, I have to unassign the interface, disable and re-enable the client config. I don’t have to do any change in the config, and that puzzles me.

Because of this, I can’t properly create FW and NAT rules for different connections.

I’m running the version 22.01 on SG-2100 and the openvpn version is 2.5.4.

Did anyone see such behavior before?

[viragomann]

@mgi said in OpenVPN client drops after assigning interface:

route 10.0.0.0 255.0.0.0

Why you are routing the whole 10.0.0.0/8 over the VPN???
This includes your own local subnet.

[mgi]

@viragomann because many of my customers use 10.x.y.z networks and it’s much easier to cover that by one aggregated route.

I see no problem with the routing as my network is local and direct route + more specific. I’m already using the same config on my EdgeRouter, but I need to migrate it to pfSense.

I’m more confused about why assigning a port to an interface is causing TLS errors.

[mgi]

I also enabled verbosity level 11, but didn’t get anything more useful.

…
Apr  2 20:56:08 pfSense openvpn[66365]: Incoming Ciphertext -> TLS
Apr  2 20:56:08 pfSense openvpn[66365]: SSL state (connect): SSLv3/TLS read server certificate request
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY WARNING: depth=0, unable to get certificate CRL: CN=OpenVPN Server
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY WARNING: depth=1, unable to get certificate CRL: CN=OpenVPN CA
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY OK: depth=1, CN=OpenVPN CA
Apr  2 20:56:08 pfSense openvpn[66365]: Certificate does not have key usage extension
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY KU ERROR
Apr  2 20:56:08 pfSense openvpn[66365]: SSL alert (write): fatal: unknown CA
Apr  2 20:56:08 pfSense openvpn[66365]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr  2 20:56:08 pfSense openvpn[66365]: TLS_ERROR: BIO read tls_read_plaintext error
Apr  2 20:56:08 pfSense openvpn[66365]: TLS Error: TLS object -> incoming plaintext read error
Apr  2 20:56:08 pfSense openvpn[66365]: TLS Error: TLS handshake failed
…

I’m still confused why the port assignment can break it so bad.

[mgi]

So I discovered two things today:

1. When I make two changes to the VPN (e.g. change and revert debug level), the VPN comes up.

2. When I restart the VPN from CLI using the pfSsh.php playback svc restart openvpn client 2 command, I can replicate the same behaviour. Even stop and start doesn’t help, and I have to change the VPN config in the web gui and save. Weird…

[MrHobbles]

I just wanted to say that I have exactly the same issue, and it's been driving me nuts since 2.6.0 was released.

Then I tried your trick of changing log level and back again...and it worked. VPN came up.

How odd.

[mgi]

@mrhobbles

Yeah, it's weird.

I'm now 99% done migrating my network to pfSense, so the client VPN is stable when I'm not touching the interface or rules.

I'm not sure if this might have something to do with S2S with OpenVPN AS or if it is a general issue.

I plan to replace the OVPN AS with pfSense VM when I have some time, so hopefully, that will work better.

[JohnSheridan]

Hi,

I have the same issue and narrowed it down to the following:

• the client had an old certificate without EKU (extended key usage). Clients with newer certificates with EKU work.
• the problem is, that "remote-cert client" comes into the openvpn server configuration, enforcing exactly the check of the above.
• this options comes in the config if I restart the daemon ("Status=>OpenVPN"), regardless of the "Client Certificate Key Usage Validation" configuration option in the web interface
• however, if I save the configuration in the web interface, the option does NOT come when it is not ticked and the server works. But after a restart, the option is back in the config.

I filed bug #13077, but it was immediately rejected, but I am really able to reproduce this again and again. Before the upgrade to 2.6.0 (before this new option actually was introduced) everything was working flawlessly.

I recreated the certificates for now, as it then works with or without that option.

[JohnSheridan]

Seems to be fixed now via bug #13056:

https://redmine.pfsense.org/projects/pfsense/repository/1/revisions/48cf54f850c5bf4fe26a8e33deb449807e71c204/diff

The diff works for me, the remote-cert-tls option can now be turned off again even over a server restart.

[mgi]

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch.

This will be probably fixed in one of the next releases then.