@Conger1892 said in ERR_TUNNEL_CONNECTION_FAILED:

I can access the firewall and other servers via the IP address

So .... fire up a text editor and open the 'ovpn' file you've imported into your OpenVPN client app, and replace the host name that it is using, for the current WAN IP you use to connect the OpenVPN to the OpenVPN.
Import this edited file.
Use it ... and now it connects !?

I presume that the somewhat vague error shown "ERR_TUNNEL_CONNECTION_FAILED." measn that the tunnel couldn't create, because the IP (the host name it was using) didn't point anymore to your WAN IP (pfSEnse work) but to 'some one else'.
So, by now you get it : the host name you were using in the OpenVPN client app config wasn't 'actual' anymore.
So, its the "DynDNS" WAN IP updater process that stopped doing its thing.

That would leave lines with errors in the (system, I guess ?) logs.

I can access the firewall and other servers via the IP address

Also : this means you have a VPN access, and you can access your pfSense directly using it's WAN IP ?
Great that you could use that solution.
A pure catastrophe from a point of security ...

, but no longer via DNS resolution.

What you wrote there, for me, is the origin of your your issue.
Who or what makes that the host name, after resolving, point to your WAN IP ?
You would say : My dyndns supplier.
Then me : And who informs your dyndns that an (your WAN) IP change happened ?
You would say : my pfSense.
Then me : Who learned this trick you your pfSense, who set it up ?
You : Me !
I would say : Great, I'm talking to the right person then. Did you start a renewal manually of your DynDNS, and checked what happened ? The DynDNS host name changed ? or not ?
If you want details - the ones that will bring you to the source of the issue, check this one :
0d68dbcd-d58f-493e-aa46-7f04adb96e0a-image.png
and renew again.

Btw : my phrases are based upon what your words told me.
I could be totally wrong of course, so please add more details.

@viragomann
Now I managed to get full tunnel and get internet in connected devices.
Sorry to make this a very long discussion.
Thank you all.
If you don't mind, could you please delete the certificate chat section in this discussion ?

@ncohafmuta said in OpenVPN on 2.7.1 crashes on some circumstances:

I'm running pfsense 2.7.1

Be aware that those who are using 2.7.1 are not the persons who visit this forum.
As they would see right away that 2.7.2 was avaible. Did you test 2.7.2 ?

I'd love to add more details, but 2.7.1 is more then two years old and I can't recall any related info anymore.

Just so it's clear:

OpenVPN Client Export version 1.9.5 isn't available on the 24.03 package repository. It's only available in the 24.11 package repository.

No packages from the 24.11 repository should be installed on 24.03. Either upgrade to 24.11 first, or ensure the update branch is set to stay on 24.03.

On the current versions that update branch doesn't automatically get set to the latest version so you'd have to go out of your way to land in this situation.

@GuillaumeJ
Try to follow the steps mentioned in their official guide for pfSense:

Proton VPN over pfSense

Regarding your question:

Once you are in NAT > Outbound, you should go to the tab:

Manual Outbound NAT rule generation.
(AON - Advanced Outbound NAT)

here you should see the automatic rules created.

Actually I have Proton VPN over pfSense working, although I'm getting some strange random issue I'm trying to investigate.

Hope it helps

@joaobarbi said in Setup OpenVPN to redirect all traffic directly to WAN:

Now, instead of routing traffic through the enterprise network, I want to use the VPN to redirect traffic directly to the WAN, bypassing the enterprise's internal network

Which path though the internal network does the traffic actually take now?

If you run an OpenVPN server on your firewall, routing all clients upstream traffic over it (for whatever reason..), the packets come in on the VPN interface and go out on WAN.
I cannot think of any shorter path.

@Gertjan OK thanks, I didn't realize that the DNS name is tied to the pfSense user name used when connecting to the OpenVPN server.

@blackslash

They were fire-walling port 1194 UDP traffic ?
They are anti OpenVPN ?

@Decepticon yup thanks!

@viragomann Thank you for mentioning CSOs, I was missing the CSO for the new building thus the VPN connection wasn't working properly. I cloned the existing one and everything works fine.
Thanks and have a nice day!

@AnthonyW
Hi Anthony, as I face the same issue with my users frequently getting disconnected due to inactivity timeout. I found your KB here, however I can't see https://forum.pfsense.org/index.php?topic=138984.0
could you please explain how to resolve or guide me the correct forum to find the resolution.

@Gertjan GASIONSERVER was udp only because ewon protocol is udp

@coreybrett said in can a firewall connection route packets ?:

Does the established firewall connection on Site B's router allow packets from Site's B LAN to be routed back

If incoming traffic was allowed to reach 'a place', the firewall (router) states will handle the traffic going back.

Your example :
With your phone as a VPN client, you can connect to the VPN server, site A. The firewall rules of the VPN server on site A will decide 'where' you can go.
Let's presume a "pass all" so you can go to every known address on site A.
So you can access, site A, pfSense itself, all all its LAN type interfaces, and why not, all it's available WAN interfaces, and one of the WAN interfaces is probably the VPN "site to site" link that connects Site A to Site B.
So, if your phone, using the VPN to site A, wants to access an IP address that exists on site B, and pfSense Site A knows that that IP (network) is reachable somewhere on Site B, it will transfer your phone traffic to Site B over the existing route, your site to site (VPN) connection.
Traffic coming in Site B will, if local firewall rules allow it, reach the final IP.

The traffic going back, as traffic is a dual direction stream, will be handled by all the routers involved. That's the beauty of using stateful router/firewalls.

After all, when you set up a connection to www.facebook.com through I don't know how many routers, the traffic reaches Facebook.
And - now your are not surprised ( ? ! ) - that you get an answer back.

@Gertjan Seemed to be an issue with the openvpn tunnel, I must have done something to it while adding express vpn. Recreating it helped.

@stephenw10 said in Setting up ExpressVPN using OpenVPN:

FQDN

But they didn't give me any DNS information at all. They just kept telling me to use the app or buy their expensive $190 Alcove Router.

The reason why I'm building this router is because my old router that I was using ExpressVPN on was only getting like 28Mb/s download through the router.

But when I used the app on my PC I would get near full speed of my internet connection. They told me it's because my old router is to weak to run a VPN that's why it's so slow.

But now this PFSense is running well into the hundreds. I have a 500Mb/s download and I'm getting like 400Mb/s. The machine it's running on cost me $55.

Anyway I've done some more test it seems that my DSN is showing up where I place my VPN location. So I think it's working as is.

I think my problems has been resolved. Thank you for all your help. ☺

Now I'm going to watch some youtube to learn more about this program.

@sxefadim Anybody?

@thomalv
Add a rule to the WAN2 interface tab to allow access to the OpenVPN server, state a unique description and ensure, that it is applied to the incoming traffic to the server.

Remove floating pass rules or pass rules on interface group tabs, which may match the OpenVPN traffic, if any.
For connections passed by these rules, the reply-to isn't set. But it's required to send reply packets back to the correct gateway.

Note that floating quick rules and interface group rules have precedence over member interface rules. So you have to ensure, that none of these match the VPN traffic.

@Gertjan Unfortunately, that was pretty much the entirety of the openVPN log.

I did figure out the problem. It had already been a long day getting this network updated, and in my haste to configure the openVPN server I overlooked the IPv4 Tunnel Network entry. After a good night's rest and looking at my configuration anew, I noticed my mistake, I entered the required tunnel network, and the service started without any more errors.

Thank you for your reply.

@delphi5
Why didn't you open a new topic for your issue?

Regarding your issue, why don't you run the peer to peer server on pfSense? You can run multiple OpenVPN servers for different purposes and as well clients concurrently.

Gateway distribution: Some of our clients use 10.10.10.1 (pfSense) as their gateway, while others use 10.10.10.2 (VPN server).
The second VPN server (10.10.10.2) is configured as a tunnel between two locations: one in our company and the other in Canada.

Why are the local clients configured to use the second server as default gateway at all?
Just add static routes to them for the remote network.

However, more reliable if you want to run this connection on a different server, would be to put it in a different network segment than LAN and route the traffic on pfSense. So all local devices could use pfSense as default gateway.