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

@kwessel Ensure that the local subnets off all sites do not overlap. Check to routing table on server and concerned clients and ensure that the routes are added properly

@Unoptanio It means that someone is trying connect to your VPN server or otherwise trying to communicate with the port that OpenVPN is running at (default 1194). Because you have enabled TLS Auth in your OpenVPN Server settings the OpenVPN Server expects that the incoming packet contains HMAC which it does not and thus nothing more happens. So it's really nothing to worry about, it's just the security layers working as they should. You can potentially reduce the amount of noise (random connection attempts) by running the OpenVPN Server on another port than default but there's not much reason to do so.

@Gertjan but also in your firewall there are all these strangers ringing the bell? [image: 1695307289097-3b6b29dd-9b05-40d4-9dc6-4f2a1aadc099-image.png]

@rajukarthik What are your rules on the OpenVPN interface? If your rules allow the access it should work normally.

@Gertjan nope the live PFSense box :)

@0t73r It behaves equal with Wireguard. After configuring an instance, pfSense creates the Wireguard group on the rules page. But you have to assign a unique interface to your instance for your rules and remove all from the group tab.

Continuing my monolouge here It seems like openSSL might have done some changes, that affects openVPN clients versioned 2.6.xx+ I think also something that affects certificate encryption. And i noticed a new settings field in the 2.7 openVPN Client export. [image: 1695188692911-f799358e-e425-4e15-8293-191dcf8cddec-image.png] My steps to reproduce: Have a Win PC with an openVPN Client export installer (latest from pfS 2.6) - Current Windows Installers (2.5.8-Ix04): If you try to connect to the pfS 2.6 openVPN server , all is good. Then you get/receive a pfSense 2.7 Client export install file , and install it (to install the new conf+certs for that connection) - Current Windows Installers (2.6.5-Ix001): Now if i try to connect to the "Old pfS 2.6" OVPN Server, I get asked for uid/pwd as usual. But after entering that correct, i get another "gui prompt" , asking for the cert passwd. [image: 1695189784507-7ef967d0-5eb3-4afd-8f0c-8a95c1f77d81-image.png] Since i never used/generated a cert passwd, i can't login anymore. Connecting to the 2.7 OVPN server, with the new client, does not ask for a cert passwd. It might be an "Odd test" , but I think someone could have both 2.7 & 2.6 openVPN servers in prod. Could Netgate confirm the above issue/situation ? /Bingo

I was able to get my ISP to give me a publicly accessible IP address for my WAN. This has solved my problem. Thanks for all the suggestions.