@viragomann Thanks a lot - I will try that

Ahh this is resolved. Would have helped to read the post directly below mine...
https://forum.netgate.com/topic/183242/how-to-route-traffic-from-openvpn-remote-clients-to-subnets-through-site-to-site-tunnels

Creating a P2 for the other site of the OVPN network on the LAN B firewall resolved this issue.

@Alpine34
Your virtual IP seems odd. How did you configure the OpenVPN server and the CSO?
Which topology does the server use? If subnet, which is default, you have to state a single IP with the proper tunnel mask in the CSO, e.g. 10.31.180.230/24.

And generally it would be wise to limit the access for the whole tunnel subnet (for any users) and give more privileges to certain CSO users.

@alanbaker The same way you would secure access to the computer/file system.

There is no way to actually secure an ovpn file, however, you can secure everything else before reaching the file like shared folders, user accounts, MFA, proper USB policies, antivirus software, etc.

If you're already using LDAP with SSL Certificates, from the network perspective, you should be good.

@viragomann

Thank you for your help, it is working now.

I know, this isn't any exciting topic. Could at least anyone confirm the restarts of unbound caused by OpenVPN Server Changes ?

@m5ip25
Just wanted to say that this seems similar to the issue I'm experiencing after updating to 2.7.0. In my case it's a simple point to point tap bridged to physical interfaces on each end. Tap needed because the whole purpose of the tunnel is to pass multicast video traffic.
https://forum.netgate.com/topic/183115/openvpn-client-process-fails-after-upgrade-to-2-7-0

@sandie Switching to /29 sounds like it should work. Recently, I realized that there was already a solution to my question in the documentation link and I missed it somehow. In PFSense version 2.7, we can use a static route assignment and that should get the routing to work.

DCO and Routing

DCO does not currently honor internal routes from client-specific overrides (i.e. iroute) for multiple site-to-site clients on a single server, but it does honor kernel route destinations that would normally be ignored by non-DCO OpenVPN.

Assign clients static addresses in overrides (after patching #13274) and then setup custom routes in OpenVPN custom options with complete destinations defined or even setup FRR and exchange routes via BGP.

@viragomann thank you for taking the time to take a look at my issue and provide these steps. It took me a couple of days of fiddling and reading to realize what you meant by a /30 tunnel. This documentation is key:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-tunnel.html

Once I set the subnet tunnel to /30, I also had to manually add remote subnet and tunnel subnet to the client's OpenVPN settings (this isn't required for larger subnets) everything just worked.

Awesome, thanks again.

So an update, I manually rebuilt my config in a Hyper-V VM and well and behold it just worked. So then I upgraded again from 2.6 to 2.7 on my physical hardware and the same issue occurred.

This time though I noticed there was mention of OpenVPN (redmine #14646) in the System Patches package so I applied all of the patches, and rebooted, and again the two OpenVPN clients did not route traffic. Strange.

I then went in to the two OpenVPN client configuration checked all of the settings compared to the VM and the only differences I had set on the VM compared to my bare metal upgrade install were:

Exit Notify - set to Retry 1x Ping Settings - Interval - 5 Ping Settings - Timeout - 30 Compression - Disable Compression [Omit Preference]

I applied the above settings to the two client VPN configurations and rebooted, and the gateways came up green.

I checked the route table between 2.7 not working bare metal and 2.7 working and they were identical.

Maybe something in the above OpenVPN settings or in conjunction that system patch fixed it. I don't really know. At least now it seems to be working

@viragomann
Sorry about that - server log attached.
Couldn't insert it here inline because it kept being flagged as spam
server_log.txt

As I received no reply here to confirm whether my issues are actually issues or user error, I have opened a bug tracker:

https://redmine.pfsense.org/issues/14816

@viragomann Thank you, that did the trick. In the rule I changed:

Destination
Destination: WAN address

to

Destination
Destination: Single host or alias 99.XXX.XXX.XXX