Hi, I am not at my machine at the moment, but I found out what this issue was.
In the 'General DNS Resolver Options' , Outgoing Network Interfaces
is set to nordVPN (as per the instructions). However if you set this to WAN, it appears to work.
To be honest I am not sure what the 'real' exposure is.
There was a OpenVPN client override. The address wasn't complete, I guess I must've missed it. I don't remember setting it at all though, maybe somebody else did.
Upon restoring some areas from the old firewall the outbound NAT was restored without matching the gateway, so that was another problem.
The finally the gateways were correct, the routes were correct but pings would only work one way.. I kept resetting things until neither could ping. I have frequent backups for both firewalls going back for almost a year, I always took them at the same time so settings would match but none seem to work.
Even after adding allow-everything rules on the tunnel I cannot get it to ping, it just stopped. Installed FRR, didn't help.
Then I tried playing with the ciphers with some interesting effects, like tanking all connectivity despite the tunnel is no set as the default gateway in either side to the one sided thing.
However, it was when I switched to shared key that I got connectivity back. It had always been as a TLS tunnel, I don't know what's different now.
But the tunnel is merely a conduit to have a static public IP disposable at any moment; it's considered as a WAN interfaced and policed as so thus I could care less about encryption security or anything else, I'm just soo grateful it works again. :D
Now I have to close it up 'cause it's still wide-open-firewall as I speak.
I tried IPsec BTW, but it had mismatching numbers, then I tried to "play its game" so to speak so I duplicated one of the P1s so the interface numbers would match. They did, but it still never connected. Since this is heavily dependent on encryption as well as the TLS OpenVPN, I think there might be something wrong with OpenSSL or whatever's behind the scenes there--that's just my highly uneducated guess though. Anyway, maybe this helps somebody else.
@griffo A new day, a bigger cup of coffee and I worked it out.
a) the NordVPN guides say to add the option tls-client to the custom config. With this option left in, it will connect but not pass traffic. There's obviously a TLS mismatch going on but it works without it.
b) with the option "Don't pull routes" NOT selected in the client, the pfsense box does not seem to give the gateway the addresses correctly. Bizarrely when I was doing a packet trace I could see the ICMP packets for the gateway monitor flying around, but in the system -> routing -> gateway screen no gateway or monitor IP was listed.
Changed those two settings and it works. Not sure if either are bugs or just a change in behavior of the new OpenVPN client version?
@Griffo Thank you sooooooooo much for writing back the solution here !
I was experiencing the exact same problem after upgrading from 2.4 to 2.5 and a tunnel interface to NordVPN.
Removing tls-client; in custom config is working fine for me too.
Wow ! Merci beaucoup !
built on Thu Sep 20 09:03:12 EDT 2018
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.
Should I uprade to it or an other one more stable ?
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.
@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.
@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.
@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...?
Don't see the problem if it works on your Linux server at max speed then it must work with pfsense can you provide logs and pcaps rules and so on because we walking in the dark with less info
Just FYI supposed you know but pfsense blocks everything so for iperf you need to create rules to open the ports high cpu can lead if you payload that port😜
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.
I finally took a chance and remotely changed the DSL to 192.168.5.0/24 so it would not conflict with the Starlink range. After a reboot, I was able to get OpenVPN to properly use the faster Starlink path. I "lost" an IoT device or two during the migration, but will eventually fi those.
@bambos Did you route the Remote Access tunnel network over the VPN on firewall B so traffic flows the other way?
Do the firewall rules on both OpenVPN tabs on both firewalls pass the necessary traffic?
@Derelict actually your first comment was right on point.
I have set on firewall B, on site to site settings, in the field of remote networks, i have added the tunnel IP of road warrior VPN. Thank you very much for your help.
I know you know, i just explain it here for future reference, maybe someone need it.
After a whole day i'm able to run stunnel with openvpn. From a fesh install of Pf. Vpn, nat,rule give the vpn working fine. i don't set any dns. Dns leak , as it seem not possible to set DOH or dot in pfsense with just : providerdns.com/dns-query.
the how: make sure Vpn is set to tcp 1194 and work fine before.
So install stunnel package / then put:
client mode check / listen ip : 127.0.0.1 /listen port: 1194
redirect to ip : vpnprovider.com / redirect to port: 443
log: notice / timeout : 0 / custom option: it,s exactly as your provider conf file. if they write option = noSslv2 , you put it all. If not it will just not work. The box custom option could be rename to : extra setting to be more clear. This is the first guide on internet.
Also, passing from a first ovpn inudp1194 do work fine, no forward port or anything else. A bit slow to get the page load directly, but all fine, dual vpn back to back.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.