OpenVPN Not working after update

Feb 21 15:06:31 openvpn 39398 WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Feb 21 15:06:31 openvpn 39398 GDG: problem writing to routing socket

that is, make them go away.
Or explain why you need them - show your openvpn server file.

This one :

Feb 21 16:45:23 openvpn 37260 ioctl(TUNSIFMODE): Device busy (errno=16)

dono what that is.
Some stray socket ?

Feb 21 16:45:23 openvpn 37260 /sbin/ifconfig ovpns1 inet6 2607:fea8:4c82:59ff::1/64 mtu 1500 up
Feb 21 16:45:24 openvpn 37260 /sbin/ifconfig ovpns1 inet6 -ifdisabled

Interface settings about IPv6 are set.
And the the interface is disabled .... ?! What about not setting any IPv6 stuff ?

This :

WARNING: experimental option --capath /var/etc/openvpn/server1/ca

is a warning that's shown since way way back. Probably not "experimental" anymore, but bthey forgot to remove the message.

Btw : my OpenVPN server bootup sequence :

2022-02-22 17:30:37.304551+01:00 	openvpn 	44221 	SIGTERM[hard,] received, process exiting
2022-02-22 17:30:37.615519+01:00 	openvpn 	47337 	OpenVPN 2.5.4 amd64-portbld-freebsd12.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 12 2022
2022-02-22 17:30:37.615772+01:00 	openvpn 	47337 	library versions: OpenSSL 1.1.1l-freebsd 24 Aug 2021, LZO 2.10
2022-02-22 17:30:37.616831+01:00 	openvpn 	47684 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-02-22 17:30:37.618389+01:00 	openvpn 	47684 	WARNING: experimental option --capath /var/etc/openvpn/server1/ca
2022-02-22 17:30:37.618744+01:00 	openvpn 	47684 	TUN/TAP device ovpns1 exists previously, keep at program end
2022-02-22 17:30:37.618869+01:00 	openvpn 	47684 	TUN/TAP device /dev/tun1 opened
2022-02-22 17:30:37.618984+01:00 	openvpn 	47684 	/sbin/ifconfig ovpns1 192.168.3.1 192.168.3.2 mtu 1500 netmask 255.255.255.0 up
2022-02-22 17:30:37.624620+01:00 	openvpn 	47684 	/sbin/ifconfig ovpns1 inet6 2001:470:dead:beef::1/64 mtu 1500 up
2022-02-22 17:30:38.630243+01:00 	openvpn 	47684 	/sbin/ifconfig ovpns1 inet6 -ifdisabled
2022-02-22 17:30:38.637215+01:00 	openvpn 	47684 	/usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.3.1 255.255.255.0 init
2022-02-22 17:30:38.645222+01:00 	openvpn 	47684 	UDPv4 link local (bound): [AF_INET]192.168.10.3:1194
2022-02-22 17:30:38.645285+01:00 	openvpn 	47684 	UDPv4 link remote: [AF_UNSPEC]
2022-02-22 17:30:38.645372+01:00 	openvpn 	47684 	NOTE: IPv4 pool size is 252, IPv6 pool size is 65536. IPv4 pool size limits the number of clients that can be served from the pool
2022-02-22 17:30:38.645466+01:00 	openvpn 	47684 	Initialization Sequence Completed

I cleaned up my config with these instructions : HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection.
I'm pretty sure a future pfSense ( == OpenVPN core) update won't break my OpenVPN server access ... again ;)

JKnott · Feb 23, 2022, 2:16 PM

@gertjan

Other than making the changes described in that sticky article, I did nothing else, so I have no idea what's causing those errors. I'm thinking about running the wizard again from scratch. I had tried restoring, but it still had the same ciphers as after I made the changes, not the ones that were there originally.

BTW, disabling IPv6 is not an option, ever.

Gertjan · Feb 23, 2022, 3:53 PM

I'm thinking about running the wizard again from scratch.

Don't.
OpenVPN, like a web or mail server can not, and will never really integrate with a web GUI to collect the settings.
This is pfSense, so you have to use the GUI. But always keep an eye on this file :

This file contains the OpenVPN server settings.
Like :

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 192.168.10.3
tls-server
server 192.168.3.0 255.255.255.0
server-ipv6 2001:dead:beef:3::/64
client-config-dir /var/etc/openvpn/server1/csc
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'xxx-yyy-vvv.net' 1"
lport 1194
management /var/etc/openvpn/server1/sock unix
max-clients 10
push "dhcp-option DOMAIN xxx-yyy-vvv.net"
push "dhcp-option DNS 192.168.3.1"
push "block-outside-dns"
push "register-dns"
push "dhcp-option NTP 192.168.1.1"
push "redirect-gateway def1"
push "redirect-gateway ipv6"
client-to-client
remote-cert-tls client
capath /var/etc/openvpn/server1/ca
cert /var/etc/openvpn/server1/cert 
key /var/etc/openvpn/server1/key 
dh /etc/dh-parameters.2048
tls-crypt /var/etc/openvpn/server1/tls-crypt 
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
data-ciphers-fallback AES-256-GCM
allow-compression asym
persist-remote-ip
float
topology subnet
status /var/log/openvpn.status

status-version 1

The last two line are part of the custom config.

My open config file is what is considered at an 'off the mill' basic OpenVPN server file.
One exception : because I have a working IPv6, I create an IPv4 and IPv6 tunnel - because 'why not'.

No need to know what all the option mean, but their usage can now be explained with the help of the OpenVPN server FAQ. Their doc doesn't care about 'pfSense GUI'.
Some option are mutual exclusive, or don't work well together.
Some are depreciated , some are right from the bleeding dev edge.
OpenVPN is daunting. The typical example of an open source project where everybody wanted his options and gadgets. I understand why the No knobs and Wheels "Wireguard" was created.

Example : this one : "Auth digest algorithm" :

auth SHA256

is needed - if it's not there, a warnings shows up :

******* WARNING *******: '--auth none' was specified. This means no authentication will be performed on received packets, meaning you CANNOT trust that the data received by the remote side have NOT been manipulated. PLEASE DO RECONSIDER THIS SETTING!

But when it's present

WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'

Because the default AES-25-CGM crypto has already a ""Auth digest algorithm" build in.

Just to name one.

Another one, when connected :

WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'

or, the keysize option isn't even present in my OpenVPN server config neither client config file. I use AES-25-CGM on both sides ....
Its usage is part of the [Deprecated Options in OpenVPN] list.(https://community.openvpn.net/openvpn/wiki/DeprecatedOptions).
Still, OpenVPN 2.5.4 is complaining it's there - or not there. Whatever.

JKnott · Feb 23, 2022, 7:21 PM

I am trying to completely remove the OpenVPN config, so that I can start completely from scratch. However, I keep running into "Cannot disable an OpenVPN instance while the interface is assigned. Remove the interface assignment first." Where is it assigned? I have removed the assignment under rules/openvpn.

After all this frustration, I'm getting to the point where I am seriously considering Wireguard.

SteveITS · Feb 23, 2022, 7:35 PM

@jknott Is it assigned in Interfaces/Interface Assignments?

JKnott · Feb 23, 2022, 7:54 PM

@steveits

No, that's for actual interfaces, such as NICs, VLANs, etc. No mention at all of VPNs in there.

JKnott · Feb 23, 2022, 8:00 PM

My mistake. I was looking under the wrong area.

Gertjan · Feb 24, 2022, 9:13 AM

Yeah, that's (2.6.0) new.

When you want to disable an OpenVPN server instance : check the disable box you get this :

Now, you have to delete or re assign the interface first :

and when done (and saved) you can go back to OpenVPN server instance an shutting it down.

Btw, strange, how little do I know.
More logic, for me, is :
First I stop all processes that uses an interface. (dns mail server web server whatever server)
Then I remove the interface.
This is the other way around.
There must be a reason why it evolved like this.

JKnott · Feb 24, 2022, 1:54 PM

@gertjan

I know about disabling a server. However, I have completely stripped out all OpenVPN config and will try again today, if I have time. After making those changes, even restoring a previous pfsense config didn't resolve the problem. This is the second time a pfsense upgrade caused me problems with OpenVPN. What made the first time even more "fun" was I could no longer use my second Internet connection for testing. It's through the same modem and works fine, unless I want to do much more than ping my firewall. So, I now have to test by tethering with my phone. However, I can or at least could get pfsense working by connecting my ThinkPad to my LAN. I pfsense configured to allow OpenVPN connections on any interface.

Gertjan · Feb 24, 2022, 2:22 PM

So, I now have to test by tethering with my phone

All I have to do, is switching the Wifi on my phone to Off.
At that moment I use my 4G/5G data carrier, and with the help of : OpenVPN Connect I connect to my pfSense as a "road warrior".
Lately, it isn't the IPv4 port 1194 UDP that kicks in, it's the IPv6 UDP port 1194 that is used.
This way, I will know it works from an 'unknown' distant IP address, which means I can access my pfSense from everywhere.

I'm pretty sure you know all this, why should you have to tether ?
No mobile network available where you are ?

JKnott · Feb 24, 2022, 2:30 PM

@gertjan said in OpenVPN Not working after update:

I'm pretty sure you know all this, why should you have to tether ?
No mobile network available where you are ?

My Internet connection is via cable modem. For testing, I use my cell phone. I can tether using either WiFi or USB. I don't know what is causing the problem with using my 2nd connection through the cable modem. It used to work fine. Then, after an update, I could no longer use it. When my laptop is connected to the 2nd port on the modem, I have a usual connection to the Internet, but now neither OpenVPN nor ssh work. Ping still does though. I can see the incoming connections, but get no response from pfsense. The IPv4 addresses are on a similar, but different subnet. Given I see the incoming traffic, it's obvious my ISP is not blocking it. My cell and Internet are with the same company, but the cell subnet is completely different from that on my Internet connections. Regardless, I should still be able to set up an OpenVPN connection, when both pfsense and my notebook are on the same LAN. That still worked after that update that killed my usual test connection.

JKnott · Feb 24, 2022, 9:47 PM

I'm about ready to give up. I completely removed all the OpenVPN settings and recreated it. I also removed all the config on my ThinkPad and recreated the connection. All the certificates and keys are correct. When I try to connect, this is what I get in the log:

Feb 24 16:34:01 openvpn 36285 Initialization Sequence Completed
Feb 24 16:36:56 openvpn 36285 tls-crypt unwrap error: packet too short
Feb 24 16:36:56 openvpn 36285 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:172.16.0.40:44802 (via ::ffff:172.16.0.1%igb1)
Feb 24 16:36:58 openvpn 36285 tls-crypt unwrap error: packet too short
Feb 24 16:36:58 openvpn 36285 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:172.16.0.40:44802 (via ::ffff:172.16.0.1%igb1)
Feb 24 16:37:02 openvpn 36285 tls-crypt unwrap error: packet too short
Feb 24 16:37:02 openvpn 36285 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:172.16.0.40:44802 (via ::ffff:172.16.0.1%igb1)
Feb 24 16:37:10 openvpn 36285 tls-crypt unwrap error: packet too short
Feb 24 16:37:10 openvpn 36285 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:172.16.0.40:44802 (via ::ffff:172.16.0.1%igb1)
Feb 24 16:37:26 openvpn 36285 tls-crypt unwrap error: packet too short
Feb 24 16:37:26 openvpn 36285 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:172.16.0.40:44802 (via ::ffff:172.16.0.1%igb1)

On the client, Wireshark shows only 5 lines of "P_CONTROL_HARD_RESET_CLIENT_V2" and nothing in reply from the server.

Again, I had working OpenVPN prior to this week. However, since the last time it worked, I upgraded to 2.6.0 and made the changes listed in the sticky at the top, so I'm not sure what the issue is.

Gertjan · Feb 25, 2022, 9:21 AM

@jknott
Compared to my openvpn server settings - see above - how is your different ?

I use Remote Access TLS/SSL ( no user password, just certs).
I have a IPv4 and a IPv6 tunnel, because, why not.

The certs are created ..... way back, as per jimp's Netgate OpenVPN server.

I use pfSense 2.6.0, so my OpenVPN server vertsion is 2.5.4. Assure jourself your OpenVPN client are also recent, not some 2.4.x series.

The cyphers should be : HEADS UP: OpenVPN deprecating shared key mode, requires TLS, deprecating cipher selection

Btw :
These :

2022-02-25 04:17:41.830847+01:00 	openvpn 	37962 	tls-crypt unwrap error: packet too short
2022-02-25 04:17:41.830878+01:00 	openvpn 	37962 	TLS Error: tls-crypt unwrapping failed from [AF_INET]146.88.240.4:37537
2022-02-25 10:03:34.546556+01:00 	openvpn 	37962 	tls-crypt unwrap error: packet too short
2022-02-25 10:03:34.546594+01:00 	openvpn 	37962 	TLS Error: tls-crypt unwrapping failed from [AF_INET]185.200.116.50:40380

are just IP's that connected to my IPv4 and don't use the correct tls ... so harmless.

Was this you :

[AF_INET6]::ffff:172.16.0.40:44802

?

Coming in over some IPv4 converted to IPv6 ....
My WAN is IPv4 only, and :

which is the default WAN firewall rule I guess.

JKnott · Feb 25, 2022, 2:04 PM

@gertjan said in OpenVPN Not working after update:

I use Remote Access TLS/SSL ( no user password, just certs).
I have a IPv4 and a IPv6 tunnel, because, why not.

Same here. Actually SSL/TLS.

I use pfSense 2.6.0, so my OpenVPN server vertsion is 2.5.4. Assure jourself your OpenVPN client are also recent, not some 2.4.x series.

This may be the problem.
openvpn-2.4.3-5.7.1.x86_64

This is the current version in OpenSUSE. Are there changes in the new version (again) that cause earlier versions to fail?

Gertjan · Feb 26, 2022, 5:17 PM