Check the OpenVPN as a WAN hangout (official Netgate documentation): https://www.youtube.com/watch?v=lp3mtR4j3Lw -Rico

@johnpoz Thank you for pointing me in the right direction - "To me pfsense WAN saw traffic to 192.168.0.255 on port 1194... Why that would be??" That was the catalyst, when I checked the 1:1 mapping there was a reference there which said WAN so I'd mistakenly transposed that for the new default WAN IP address - when it should have been the 'new' external IP for the Unifi Video - once I'd checked back over the 'old' addresses I could see that the wrong external WAN IP address was being used and so OpenVPN requests were being 1:1 translated to that LAN. Once this was corrected the OpenVPN connections are now working fine. Thanks very much for your help.

Problem you run into is how will site B box Y know you moved 192.168.18.X to the other site, if Y wants to talk to X.. He will think its local, and never send to its gateway. And as you move X over to A, how will X know that box Y is still over at site B.. Easier solution would be to use a different network say 192.168.19 or 172.16.18 as you migration network.. So you move 192.168.18.X to site A and change its IP to 172.16.18.X.. Changing any dns you need to at each site to reflect the fqdn new IP on the new site. Once you have everything moved over - you can change the 172.16.18 back to your 192.168.18 network.. And change all your dns to reflecting the correct address.

I spent hours digging into the ldaps connection issues I had through the GUI on pfsense. I used openssl s_client in the shell to determine where the issue was with the verification of the CA. openssl s_client -CAfile /etc/ssl/file.pem hostnamehere:636 Anytime I specified the CA file location openssl returned no errors... so I was perplexed why it wasn't working in the GUI. I eventually ran across this post and I am very grateful: https://forum.netgate.com/topic/145578/ldaps-ad-bind/21 Essentially after changing the LDAP authentication server to LDAPS on port 636 you MUST restart php-fpm. I did this by running option 16 in the console. I am currently on 2.4.5 I hope this post helps someone else if they find themselves in this situation.

@MBTPf said in Service stops randomly: OpenVPN service will randomly stop Hi, Is the OpenVPN service shutting down? (although I have never experienced this before) -or you lose the connection, say in the client For the first case, may be a solution the "service watchdog" with the loss of the connection, - f.e. this: OpenVPN client "Custom options": ;auth-retry nointeract

@ValP said in OpenVPN with OPP, resets after 1 hour: users list is in RADIUS. any user without OTP and I'm using login with certs. And Client override wasn't doing what I expected neither. What did work was this : [image: 1603182660529-1b8bac01-b4b5-4a17-be3f-7e55758465de-image.png] Adding "reneg-sec 3600" in "Additional configuration options" on the Client export page, and save it as a default. Then the exported opvn files will contain ... reneg-sec 3600 Keep in mind : maybe you're searching in the wrong direction. A DHCP leased used locally, or upstream, or on the other side, times out, the related IP on that interface gets renewed, processes get restarted, VPN client, server (?) and the connection is rebuild. You should crank up, and inspect, the VPN log details on both sides and check for details.

@viragomann said in OpenVPN remove client: @bingo600 said in OpenVPN remove client: Would that not prevent the user to login again ? Sure, it does, when the server is in a "User auth" mode. You can also revoke a user cert temporarily. After removing from the CRL it is accepted again by the server. Also consider, when "Strict User-CN Matching" in the server settings is not checked it will be possible for a user to use another ones cert for authentication. I'm using this (SSL/TLS + User auth) [image: 1602924226747-d81e0a60-2b25-420c-87bb-1f6f1175dad9-image.png] And have [image: 1602924297910-9a07cda2-d9ab-4b29-9a92-883ca7b7cdee-image.png] Thanx for the confirmation /Bingo

I have had the same issue i think. My Roadwarriors couldn't use the OVPN interface for DNS lokup. I cheated and gave my pihole as DNS instead. But i have a feeling it might be something w. Unbound and acceslists (for the RoadWarroir Client networks). I'll be following this one /Bingo

I have several OVPN Lan2Lan tunnels , and i never experience that the client does not keep trying to connect to the server. I do have the package service_watchdog installed on both pfsense's , and have added all openvpn instances to the service watchdog. [image: 1602917509889-8ad5a862-54f7-434a-9d39-4cdc20e84991-image.png] I occationally see service watchdog , starting unbound or ntopng. Can't remember if i have seen it start an openvpn instance. If you're talking about a RoadWarrior (dialin) OpenVPN client. I have not used a connection long enough to see it fail a connection. But i suppose you mean a L2L/S2S connection Edit: What i often see is that the "Dashboard" indicates the OpenVPN tunnel isn't up (Red down arrow) , but that is some kind of "Status mismatch" , because i can mostly connect to the remote site , even if the status says otherwise. That would be nice to get the "status arrows" fixed, so they reflect connectivity , instead of "whatever they use now" The same mismatch occurs on the Status -> OpenVPN page /Bingo

Yes. I have use $ instead £ and it works. Some copiers we have doesn't like £ sign on the password. Something to do with £ . Thanks for your clarification & much appreciated. I will remove £ from keyboards. :) :) :) :)

@johnpoz OK, I will put my problem to them and see what they say. Regards

You need to have the same CA as Issuer for the Server and Client Cert. -Rico

Try this guide. It might be easier when new to vpn server stuff. Configure OpenVPN for pfSense 2.4 The Netgate guide is more comprehensive, but sometimes overwhelming for newbies.

Wow, this "feature wish" was opened 5 (five) years ago. I would call it bug fix. So sad that dual stack is not understood as default for any node. Thanks kiokoman for the link.

Thanks! Cheers!