Problem with OpenVPN in Pfsense 2.7

Gertjan

@chedxb
That's not the best solution.
There will be a pfSense 2.8 or even 3.0 in the future. With an even more recent OpenVPN binary, and some settings will have to go, as safer, better, faster continues to be a thing.
OpenVPN is heavily 'security related' so staying in the 'past' is a bad idea.

I'm pretty sure this video, when copied 100 % identical works out of the box - and will work with 2.7.0 : Configuring OpenVPN Remote Access in pfSense Software

Keep in mind there are other VPN solutions.

chedxb

I get your point, but we use SNOM VOIP phones on the field and they support OpenVPN only.

And the problem is that we don't know why they stopped working after upgrading to 2.7, entire setup used to work perfectly before that for almost 10 years!!

chedxb

some interesting findings;

Site1: pfSense 2.7 as router/firewall, behind it a FreePBX VOIP server (works fine)
Site2: pfSense 2.6 as router/firewall, behind it a SNOM VOIP phone, connected to site 1 (SNOM VOIP phone works fine)
Site3: pfSense 2.7 as router/firewall, behind it a SNOM VOIP phone, connected to site 1 (SNOM VOIP phone connects, but no traffic)
Site4: A consumer grade router, behind it a SNOM VOIP phone, connected to site 1 (SNOM VOIP phone works fine)

It looks like pfSense 2.7 @Site3 seems to change some traffic so that the SNOM VOIP behind it connects but no traffic.

Thoughts?

banzai30

Hi @chedxb,

For me, no solution exists to downgrade with netgate solution so you need to reinstall it in 2.6 and push your config then (Backup needed before reinstalling)

I hope netgate will correct it soon in future versions.
Existing others solutions for VPN but complicated to change all infrastructure just for a bug…

chedxb

more findings,

it looks like it is a NAT related issue. SNOM VOIP connects (so OpenVPN works) but no voice from the other party. NAT settings are default, we didn't change anything.

Stef93

@banzai30
Perhaps the problem is different.

There may be a problem with pfsense with different hardware.
Perhaps you have some other settings that you did not write. When updating 2.6.0 > 2.7.0, you need to double-check everything and look at the logs for errors, also update (pfblocker, suricata, snort, etc.)
Try to completely remove the openvpn interface and configure it again, it may have been damaged during the update.

Since the problem is not widespread, I do not consider this a netgate problem, I personally started using it with version 2.5, then installed 2.6 on a clean one. And recently I updated 2.6 > 2.7. I have 3 Openvpn interfaces with partially different settings and “Redirect IPv4 Gateway” works perfectly with clients after the update. But more serious problems arose, with the discrete network card (I already bought a netgate 6100, I’m waiting to receive it).

I don’t have a final opinion on netgate yet, but I consider the CE version to be unstable, so I’m stopping using it in production

Stef93

In addition, I doubt that netgate specialists test their software on hardware, for example i5-12400, when they have their own Atom and Xeon processors (by the way, I use the old E3-1235 gateway and continue to use it. On the motherboard, 2 ports work well) , I'll leave it for testing)

Gertjan

@Stef93 said in Problem with OpenVPN in Pfsense 2.7:

Perhaps you have some other settings that you did not write

Quiet right.
Here it is /var/etc/openvpn/serverx
where x is the server ID - probbaly 1 or 2 etc.

dev ovpns1
disable-dco
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
learn-address "/usr/local/sbin/openvpn.learn-address.sh bhf.tld"
local 192.168.10.4
engine rdrand
tls-server
server 192.168.3.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'bhf.tld' 1"
lport 1194
management /var/etc/openvpn/server1/sock unix
max-clients 10
push "dhcp-option DOMAIN bhf.tld"
push "dhcp-option DNS 192.168.3.1"
push "block-outside-dns"
push "register-dns"
push "redirect-gateway def1"
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
sndbuf 1048576
rcvbuf 1048576

192.168.3.0 is my tunnel.

192.168.10.4 is my WAN IP (behind a ISP router).

My settings are nearly all "default", as advised by these people : https://openvpn.net/community-resources/.

Openvpn isn't a pfSense thing : it's a publicly available FreeBSD package from openvpn.net, and pfSense added a nice GUI to expose the most common settings (but by far not all of them).

While I can't really prove this, I know thousands are using OpenVPN on pfSense right now, as a client and as a server
The forum would 'explode' with unhappy users if OpenVPN didn't work.

Stef93

@Gertjan
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 SHA512
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 127.0.0.1
engine devcrypto
tls-server
server 10.0.250.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user ### true server1 ***
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'VPNnetServer' 1"
lport ***
management /var/etc/openvpn/server1/sock unix
push "route 10.0.0.0 255.255.0.0"
push "dhcp-option DNS 10.0.250.1"
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.4096
tls-crypt /var/etc/openvpn/server1/tls-crypt
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression asym
topology subnet
fast-io
explicit-exit-notify 1
sndbuf 262144
rcvbuf 262144
reneg-sec 0

client-connect /root/openvpn-telegram.sh

client-disconnect /root/openvpn-telegram.sh

script-security 2

Gertjan

@Stef93

Ok, I understand where "username-as-common-name" comes from.

This looks very suspect :

@Stef93 said in Problem with OpenVPN in Pfsense 2.7:

client-connect /root/openvpn-telegram.sh

client-disconnect /root/openvpn-telegram.sh

Remove them and try again.

Check your config - and the openvpn config manual :
Can there be two "client-connect" and two client-disconnect ?
There are already these :

client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh

What will happen when a second "client-connect" entry is found in the config file ?
The first gets overwritten ? Thus non executed (would be very bad) ?

Anyway : goto bare minimum, and when it works, build up from there until it breaks.

Stef93

@Gertjan
For what? I have no problems) everything works well) re-read the topic again and understand why I left the config)))