@george1116 said in OpenVPN does not work on bridged PFsense router:

My pfsense router is installed behind my home router, the LAN port on my home router which pfsense is connected to is set in bridged mode, so my pfsense WAN side is getting a public IP in the 199.x.x.x.x range.

I then installed openVPN on my pfsense router, but when I am connected directly to my home router (the bridged router) openVPN is not able to connect, however, when I connect via tethering to my mobile device hotstpo OpenVPN connects successfully.

What is the error I am getting:
When connecting to openVPN I get the below error message after some time.

2024-01-03 08:30:08.123554 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 2024-01-03 08:30:08.123640 TLS Error: TLS handshake failed

What have I checked:

I checked my home router to see if port 1194 is blocked, and it isn't I verified that my pfsene router WAN side is indeed getting a public IP and it is. I ensured there is no double NATing, this is evident from the public IP on pfsense WAN I used Packet Capture to verify that indeed there was an outbound connection from my machine to pfsense router, and there was. I changed the Tunnel Network of OpenVPN, but it didn't help I used different authentication Modes, but it didn't work

I have been going on for 2 days now, has anyone experienced this or knows what the problem could be

I think the router in front of your firewall is causing the issues, is this a standard ISP issued router with a dmark or a modem?

@Diablo666-0 said in OpenVPN with Remote Access (SSL/TLS + User Auth) // Auth Certificate issue:

Everything is working fine, but suppose I have two users, A and B. When I try to connect with the profile (file .ovpn) of user B using the credentials of user A, it works.

To avoid this, go to the server settings and check "Strict User-CN Matching" in the "Cryptographic Settings" section.
Ensure that the CN in the client certificate matches the username.

Additionally, when I remove the certificate of user A, for example, they can still connect to the VPN.

Removing a valid client certificate is a bad idea at all. This cannot prohibit that the OpenVPN server is accepting it, because the server only verifies that the delivered client certificate is singed by the CA in use.
To reject a client certificate you have to revoke it instead.

Maybe you need to create a revocation list first (System > Certificates > Revocation) and add it the the OpenVPN server then.

You may remove a certificate after its expiration though.

@JonH they also have a windows release, just a exe you can run.. Thats what I used in my screenshot

@evangelos-ziakas

Would need your host configuration screen shots.

Sounds like each device is connecting to a different host (server) configuration. As in having multiple dial-in servers with different tunnel networks.

@notcloud

I used this article very sucessfully with my transition from Shared Key to TSL.

Look at your routing tables to ensure all the routes were auto-created

Status-OpenVPN - Click Show Routes - this shows the VLAN to Public IP routes
Diagnostics-Routes - this shows all the routes - should have your remote sites (example: 192.168.1.0/24) mapped to the destination IP of your VLAN - example, you set up the Tunnel network as 10.10.9.0/24, and the remote site connected as 10.10.9.2. This means the host (server) is 10.10.9.1. The route should show Destination=192.168.11.0/24 Gateway=10.10.9.2.

On your client the route would be if the host network is 10.10.10.0/24: Destination=10.10.10.0/24 Gateway=10.10.9.1.

You may need to restart the host server to get the routes updates - I did.

Interesting, there is an option to use SHA1 certs(?) with openssl 3.x:
https://github.com/OpenVPN/openvpn/blob/master/Changes.rst

--tls-cert-profile insecure

I set this option (for testing only) and now it look like:

ink remote: xx.xx.xx.xx TLS: Initial packet from xx.xx.xx.xx Connection reset, restarting [-1]

@viragomann

Hell :(

I can't get both server IP and ubuntu box to operate at the same time.

I guess I will live like this for now.

Thx for your help!

Thanks that fixed my issue also, I was wondering what that was.

Looks like that could only happen if there were no certificates on the system at all, which is exceedingly rare. Someone would have to change the GUI to HTTP (dangerous enough as it is) and also delete the default GUI certificate.

The code could handle that better, but it's still not something anyone should be hitting.

You could make a certificate for now to work around it, either manually or by generating a GUI cert with pfSsh,php playback generateguicert from an SSH or console shell prompt.

@lifespeed

My prefix has been the same for almost 5 years. However, this is one reason I mentioned ULA. It won´t change, unless you change it.

There's not much to subnet. You just assign a /64 to each interface.

@franco5 said in Dial-in cannot communicate with Site to site:

I add the networks local and remote in each configuration setting of Openvpn,

On pfSense 2 you have to add "192.168.2.0/24,10.10.10.0/24" to the "Remote Networks" in the server settings.

I add push "route 192.168.1.0 255.255.255.0" in Openvpn dial-in client, I add a static route in PFsense to route 192.168.1.0 by 192.168.101.1

These are not needed.

On pfSense 2 you have also to add a CSO for the S2S client and state "192.168.2.0/24,10.10.10.0/24" as "Remote Networks" in the settings.

I got it! 🎉 Right after I posted, I saw the log state that the vpn link did not have an ip address. I looked and the local address was my public ip. 😕 I manually set the IPv4 Tunnel Network on my client through the web gui and it worked. I now have a the route and I can ping in both directions. I think it also needs the gateway to be pushed. I'll play around a little more tomorrow just to see the actual reason. I am not sure why it wasn't getting an address without the tunnel network being predefined. I also gave the client vpn an interface. So I'm not sure if that is also required.

@SteveITS said in About Cryptographic Accelerator Support:

@mcury openVPN does its own thing, take a look at https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-crypto.html#hardware-crypto

hmmm, thanks SteveITS.

I did some tests right now, disabled Intel QuickAssist (QAT) and enabled AES-NI and BSD Crypto Device (aesni,cryptodev), then rebooted.

Kept Intel RDRAND engine -RAND enabled in the OpenVPN client settings, and indeed I can't see any difference in performance and/or resources usage in the Firewall.

Since I'm not using QAT, I'll keep it disabled, and will use AES-NI and BSD Crypto Device and Intel RDRAND in OpenVPN, along with IPSEC-MB to help Wireguard.

Thanks again SteveITS 👍