I'm coming back to this as this was not resolved and would like this to be taken care of.
I thought instead of "saving" the vpn configuration on the main server I'd try rebooting the main firewall instead to see if that would rectify the problem. It didn't. It appears that when the main internet drops and the firewall switches to the "backup", there is a VPN setting that is getting corrupted (either gets hung up on the switch and doesn't switch back, or some other setting that gets flipped, but gets reset when I click save).
I have attached the server VPN log Server VPN.txt and client VPN log Client VPN.txt from 6pm to 8am (outage was 7:30pm to 8:30pm)
I am also attaching the main server log Server Main Log.txt
I noticed this line
OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW
Is this not reloading correctly?
Thanks in advance...

I also have an OpenVPN site to site tunnel between this pfsense box and another. I get the same symptom set on both pfsense boxes.

@viragomann I indeed missed that part of the docs. Thank you VERY much!!

Update: I needed a state reset for the block rules to work. I am now blocking connections to ovpn from the lan so that is a solid workaround. I still would like to know what changed.

In case anyone has the same problem, this is what I ended up getting back from Netgate support:

"Unfortunately it's not supported to have multiple OpenVPN TAP servers bridging to the same interface"

@viragomann I'll have to try again with Wireshark running on the VPN client, but the command prompt on that PC was showing a timeout.

At first glance, it seems to be an issue of translating back from the LAN subnet to the VPN Tunnel subnet.

Yes Sir!

Many thanks for the speedy response.

Kind regards,
jB 😎

@bafcharles

what version of pfS ?
maybe deprecheated version
best guess go and update your box to 2.5.1

brNP

As mentioned already you need correct routing, and you would need correct rules in your openvpn interface on both ends.. Pretty sure it default to any any.

Another mistake common, is policy routing being done with would shove traffic out the wrong interface and not allow pfsense to send traffic out the vpn interface.

Another common issue is host firewall on where your trying to go, etc.

You can already get lport 0 by setting the option to randomize the local port, though I can't recall off the top of my head if that is the default. I don't think it has a way to set nobind.

If it doesn't set that by default, we should probably update the package to work that way and use nobind.

@bcruze said in OpenVPN 2.5 released - Overview of changes:

Did you update Pfsense somehow?

No, I just used the new Windows-Client with the Server on pfSense.

Thanks to viragomann, the problem is solved. The problem is that the default gateway for devices in the client lan is not pfSense, we need to setup NAT mapping as a work around. Really appreciate the help @viragomann !

@viragomann completely agree.. Lets see what it shows.

@johnpoz said in LAN to local server rule?:

NOT the correct way to do it.. but OK.

then please propose the better one
Prior to change I identified the passing rule:
Screenshot from 2021-06-18 15-35-22.png
192.168.5.0/24 is LAN, 192.168.101.0/24 is a subnet on the other site.
VPN_S2S is the interface added for ovpnsX according to Assigning OpenVPN Interfaces in the doc.

I see my current configuration to be inline with this Tip from the docs:
"The best practice is to create manual negation rules at the top of internal interfaces such as LAN. These rules should pass to local and VPN destinations without a gateway set on the rule, to honor the system routing table. "

@bob-dig said in VPN (Surfshark) not working after reboot:

I do a nightly reboot of my pfSense via cron.

So I added another cron job (rc.reload_all) after that one and this does it for me. All in all a little bit to complicated for my taste.

@juancho1981 said in two openvpn:

But if I have the network added in the tunnel

On both OpenVPN servers?

Post the routing table of both clients when they are connected.

Ensure that the destination device in 10.6.0.x doesn't block the access by its own firewall.