@amir75 said in SSL VPN goes down: "Version 2.4.4-RELEASE (amd64) built on Thu Sep 20 09:03:12 EDT 2018 FreeBSD 11.2-RELEASE-p3 The system is on the latest version." Yeah, that's known. The package system is brain dead, or DNS settings have been broken by the admin, the file system got a blow in the face by a power loss, etc - and he system says it's up to date (because it fails to prove otherwise). Or, TV channels, Youtube (thousands !), the Netgate's announcement blog (twitter, redit, etc) , or the thousands of messages posted on this forum might have inform you that 2.5.0 is out and 2.5.1 is coming. @amir75 said in SSL VPN goes down: Should I uprade to it or an other one more stable ? Maybe. My personal advise is : play with it first. And if it pleases you, upgrade. I now, it's 2021, but I say it ones more : always prepare a way to retrograde. If you can go back, you will never do so (extension of Murphy's law). At least, read about it. See if there are current issues with functionalities that you use. For me, 2.5.0 vanilla on a I5 box is just great, better as 2.4.5-p3 which was already more then ok (for me ) - VPN server for remote access works - and recently I discovered that OpenVPN client works ( for me : using Expr*ssVPN where many said : it's broken, so go figure )

I turned on the “Allow multiple concurrent connections from the same user” option only after the original post in this thread. With that checked, two concurrent clients using the same certificates get distinct IP addresses. That option turns on a configuration line in /var/etc/openvpn/server* that says duplicate-cn A post on ServerFault had pointed me in that direction.

@bambos said in OPENVPN to secondary LAN: @hossimo to my understanding, restarting the open vpn service rebuilds the routes of accessible networks again. so it's important to restart the service on any change. That does seem to be the case in this instance. After some additional testing I found that removing or adding the interface deleted the routes and restarting the solved it. I should have just restarted the router in the evening and that would have also brought it back, at worse it would have been a trip to the color, but know I know I can just restart the service to the same effect.

Maybe this is the best way to solve the issue: [image: 1617765546112-screen-shot-2021-04-06-at-11.18.36-pm.png] Are there any opinions out there, as to which approach is best?

The only thing that might be in there you want to redact should be pretty obvious ;) Say your public IP, or fqdn your connecting to..

@jim-coogan thank you my friend. seems watchdog is easier package for that purpose, allows to monitor active services by selection and monitors, restarts, and notify without commands. Looks like a good start. Thank you for your comments.

@gertjan hello Sir, I did some investigation and didn't find yet why the wan go down, though it never happent again. i'm thinking to implement a cron restart or watchdog for the services. Thanks for your comments, i really appreciate your help.

@ximulate The simple change that has worked for me so far: make sure "Do not check" is set on the server's certificate Depth Check option. This seems to bypass a potential bug with Certificate tests that can be pretty random seeming. May not solve your issue but probably won't hurt and helped me.

@jknott I set up the VPN from scratch and it worked. I then tried it again later and I get the hard resets again. Is there something that happens between connection attempts that kills it?

@zmaliz anyone have any ideas on this ? Thanks

I've got a similar issue: Apr 5 11:29:09 pfsense openvpn[66140]: Using peer cipher 'AES-256-CBC' Apr 5 11:29:09 pfsense openvpn[66140]: OpenSSL: error:0201502D:system library:ioctl:Operation not supported Apr 5 11:29:09 pfsense openvpn[66140]: EVP cipher init #2 Apr 5 11:29:09 pfsense openvpn[66140]: Exiting due to fatal erro I'm on 2.5.1.r.20210405.0300

@comfy Ok - so, got it working - an auth issue. So, the next question would be (that ive created an alias group of the devices i want to route through that connection - is there a walkthrough somewhere...?

@gertjan Yep I read that, great work! I no longer can test this myself as I no longer have the subscription to azirevpn where I was having the same issue as this entire thread, was just curious if it helped anyone

This is most likely due to NCP, I guess you have it enabled. You can ignore the warning.

@yv5 said in Has anyone found solution for ExpressVPN?: I have followed it ...think 10-15 time with no luck Sorry for my late reply, the OVH DC (French) fire, caused a lot of work for me, but I see @Gertjan helped

@viragomann You are a life saver! I had a floating rule for 1194 which I didn't remember creating. Thank you so much!

@sensewolf said in OpenVPN only for certain network?: @fearnight said in OpenVPN only for certain network?: Just wanted to chime in and say I finally got my setup working after finding this thread. All I had to do was uncheck "Don't pull routes" and it started working. I was having the same symptoms as @sensewolf before. Sorry, did you mean to say you checked the box "Don't pull routes" or did you actually uncheck it (which I would find even more counter intuitive than everything else that is happening on my pfSense in this context)? Right, I typed this wrong. Sorry. I went in and "checked" the box in the OpenVPN client config. It was unchecked by default.