When renewing the Certificate Authority, navigate to the Certificate section and proceed to renew the server certificates. It is important to note that when creating a new user for the VPN, avoid using an existing user, as it may not function properly. Once you have created the new VPN user, test the functionality to ensure everything is working as expected.

@stephenw10 can you also take a look please. Thank you

@viragomann you said "assigning an interface to the VPN instance gives you a gateway. " probably I'm confusing "assigning an interface to the VPN instance" with "assigning a VPN instance to an interface" or something. I'll get there eventually. cheers

@Dobby_ I believe you. Thank you and @SteveITS for the assistance. I really appreciate you guys taking the time to help. I will check speeds again later tonight to see maximum throughput.

@jknott said in P_CONTROL_HARD_RESET_CLIENT_V2 error: @rico The NAT is at the other end. My pfsense has a public address, so no NAT needed at this end. Here's the rule: [image: 1650482158503-121df6a2-46c0-429d-83b1-be3e7903212f-image.png] As for interfaces, I currently have UDP IPv4 and IPv6 on all interfaces, though I have tried just UDP IPv4 on WAN interface. Either way, it does the same thing. For some reason, in the OpenVPN Server you have to set the interface as any, not WAN

@bob-dig OK got it, thanks again.

@technolust said in Split Tunnel Traffic Failing for Web Traffic: It could be due to the name resolution not working but I'm not 100% sure. Do an nslookup to get sure. Or even a ping to google.com or whatever. I renamed the vpn file with redirect-gateway def1 to the original. Checked the box and the issue happens... 1.1.1.1 comes up but dns not working... Then I brought back the redirect vpn file and unchecked the box and it works Normally this is pushed to clients by the server and hence doesn't need to be set on the client, however, it's possible. You can enhance the clients log level to see, what configuration changes the client does in the OS with the line: verb 3 try to provide your pfSense IP as DNS server I have a pi-hole setup as DNS server. Should I try that IP? Yes. Possibly you have to add the VPN tunnel to the Resolver ACLs This part I don't recall how to do... This is lapsed, since the Resolver is not the DNS server. Maybe you have to configure it on the Pi-hole properly. If you provide public DNS servers without 'redirect gateway' you would also route them over the VPN by adding them to the "Local Networks". Do I need to do this under IPv4 Local network(s) in the Tunnel Settings? Yes, IPv4 addresses have to be added to the "Local IPv4 Networks", IPv6 to the respective other one. Note to use CIDR notation, e.g. for Cloudflare "1.1.1.1/32".

@jknott ... that is the plan - change the network at the new site (site B).... The guy was supposed to prepare the new site to be up and operational, however, it has never worked properly and he left without fixing all those issues..... so I'm trying to help there.... :)

So can anyone provide suggestions as to why when I am connected to my PFS box via open vpn client that I do not see the connection listed in the status>openVPN screen?

The extra files that are part of the export package handle the installation and config copy process that happens. The installer in the export package installs OpenVPN and then afterward (post install) it copies the bundled certs, config, etc.

@viragomann said in Unable to contact daemon: check the system log for hints to the reason, why the server did not start. Thanks for the suggestion. It looks like I had a few separate (unrelated) issues. The first was my logs were not actually working at all...since none of the logs had updated since 19 March 2023 (the most recent entries for the System, Firewall, DHCP, etc. logs are 19 March). Going to System Logs > Settings showed a PHP error: Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/status_logs_settings.php:72 Stack trace: #0 {main} thrown in /usr/local/www/status_logs_settings.php on line 72 PHP ERROR: Type: 1, File: /usr/local/www/status_logs_settings.php, Line: 72, Message: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/status_logs_settings.php:72 Stack trace: #0 {main} thrown This seemed related to a bug in pfSense 23.01 where if the <syslog> portion of the config.xml file is empty then this error will happen and no logging occurs. This is in the bug report here: https://redmine.pfsense.org/issues/13942 So, once I got that fixed and the logs worked again I saw that OpenVPN had the following error when starting: cannot open tun/tap dev /dev/tun1 no such file or directory pfsense ...which was related to another bug detailed here: https://redmine.pfsense.org/issues/13963 The ultimate fix for the OpenVPN issue was running the following command: kldxref /boot/kernel ...and then the OpenVPN service started immediately. Hope this might help anyone else in the same situation as me!

@scottlindner re "Is there a solution to that that can be automated?" not as far as I know. I've set up a gateway group of all 3 and set the tier priorities:- [image: 1684249832200-screenshot-2023-05-16-at-16.09.26.png] I also have a Nord LAN segment that I route all the traffic out to the gateway group:- [image: 1684249937422-screenshot-2023-05-16-at-16.09.54.png]

@mimu I'm using the OpenVPN server just as access for myself for remote administration. So, multiple connections, for me, is a rare thing. Still, I've set : [image: 1684129116528-be7e33ae-4fa9-4c02-b4c0-ff20980e0612-image.png] because : why not. I guess (OpenVPN doc should explain more), as soon as a 'client' tries to connect, a 'slot' is allocated. If you have many 'clients' that try, and these are just scripted scanners looking for less protected (NON TLS) VPN access, slots can allocated fast. Again : I guess. I've not (never) seen "I/O wait events" in my OpenVPN logs. I'm using two OpenVPN servers , port 1194 and port 1195. Both are completely separated, and work fine both. Both servers use TLS, and no user+pasword.

@parushev Is CARP working well? Check the system log for regarding entries. Is the OpenVPN server down on the secondary? Do you have a single router or is it an HA system as well? How are your pfSense boxes connected to it? Is there a switch or another device in between? Are they installed on bare metal or virtualized? Note: When a device is talking to the CARP VIP, it resolves the VIP and get the CARP MAC address and send the packet to this. However, pfSense uses its real interface address (WAN in your case), when replying. Some devices don't love this behavior. Maybe you're affected of this.

@viragomann Unfortunately, I lost access and won't be able to regain access until I revisit the site tomorrow. I didn't implement any rules on my OpenVPN server; I only selected the boxes while installing OpenVPN with the wizard to create the required rules. OpenVPN had been working before I enabled the interface and then changed the interface's name. I never implemented any rules under the interface OPT1 tab. The only rule that is implemented is under the OpenVPN tab and I believe it's just IPv4 with * in all the fields. @viragomann said in OpenVPN troubleshooting and Firewall / Rule / OpenVPN vs OPT1: Consider that rules on interface group have priority over ones on member interfaces. So if there is a pass rule allowing any to any, rules on member interfaces would not have any affect. So then enabling the OpenVPN interface creates an interface group? The single OpenVPN tab that is created when you setup the wizard is a member interface? (I don't know if this OpenVPN tab is their prior to the wizards use as I didn't look before I used the OpenVPN wizard.) @viragomann said in OpenVPN troubleshooting and Firewall / Rule / OpenVPN vs OPT1: What is the purpose of the other tab then? I'm trying to understand the difference between the rules associated with the tab created when you enable the OpenVPN interface in assignments and the rules made under the tab that is purely labeled OpenVPN.

@tank330 Never resolved the issue..the mute-reply warnings are still there. Just clutters up the logs...

@dbadovsky Yeah, it has to be in the client specific file, mentioned above. Nice that you got it sorted.

All sorted now, a couple of badly configured alias's were the issue and have now been rectified. all is working now as desired.