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

@pf-makes-sense said in OpenVPN server deamon does not start with pfSense 2.7: OpenVPN deamon does not start with 2.7 Can you show the OpenVPN logs Status > System Logs > OpenVPN when it starts ? [image: 1695708306381-4cb1dd48-a007-4a77-8d7b-7ae62625d56c-image.png] You don't want Encryption also ? [image: 1695708367319-c3d1a813-969d-44d9-a1da-436beeb4a577-image.png] Get rid of the CBC. Also on the fallback. [image: 1695708505107-634999e4-f125-414a-9ddc-53b4cb0c8a63-image.png] If compression doesn't bite you today, it will tomorrow. Be ready for the future : [image: 1695708568728-cb6f1507-5fd0-4245-b3cd-b3260b5f52c5-image.png] [image: 1695708603381-6873c30b-47c5-4309-9d64-8d45af461391-image.png] Double triple check that you can access this IP. It's the LAN IP right ? You could also use 10.0.8.1:53 as unbound should be listing to that one also. But : check that. This : [image: 1695708911755-f566c9c6-56c8-4b4a-a2a3-1edd1c6c5baf-image.png] is strange. After the custom box I have not this "Username as Common name" : [image: 1695708969876-a9360ff8-fe02-4096-a1ee-36d942445410-image.png] So pfSense 2.7.0 is not 23.05.1 ? If you have 7 minutes spare somewhere, set up a second OpenVPN (using another UDP port) server using the official OpenVPN "set up a remote access OpenVPN" - see the official Netgate channel on Youtube. Or use the Wizard. Get a good known working OpenVPN client from the official source.

@IntrusionDetector Nice you got it working /Bingo