PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
Quick followup-
Not had time to mess with it.
2.5 did not work out for me on any of the three systems that I ran the update on.
Both IPSEC and OpenVPN broken after update both no longer connect/work.
All 3 sites had a caching DNS and no longer work.
I can easily tell from all the posts that it is not just me or my setups.
For now- had to reinstall older version and restore from backup.Had to get the latest 2.4 from another users because somebody thinks it's some kind of good
idea to INSTANTLY make the previous WORKING version no longer available.
Complete and total arse headed move...
And who ever makes this decision can seriously stick it.
I'll come back to this and troubleshoot when I have time.Too many exchange servers to fix right now keeping me busy and great pay.
Maybe all of these broken issues will be fixed in 2.5.1
2.5 is obviously not release worthy and nothing was checked on it for upgradeability.
And I have the simplest setups to upgrade about as basic and featureless as it gets.2.4 is rock solid and has always worked well.
-
Hi,
I feel the same. First I was fighting openvpn after the upgrade. I had to reinstall and restore from backup to get openvpn working. And now I am experiencing an issue with unbound ignoring pfblockerng blocklists. The only solution to solve this seems reinstalling and restoring from backup. But I am asking myself seriously if I want te reinstall version 2.5 or just go back to 2.4.5 where everything was working fine. And indeed bad move from netgate in immediately removing 2.4.5 from the downloads site. I found the old version on some transit.NL mirror :( -
Very bad move and I just made a separate post about it.
How can that possibly be good or helpful in any way? -
Hi, any update to this? I just ran an update to ver. 2.5 and am seeing the same thing. OpenVPN stops working.
In my setup, I was in version 2.4.4 for multiple sites. I upgraded the site that has the VPN SERVERS setup, and the remote VPN's (still on 2.4.4) continued to work normally, even after re-boots.
As soon as I upgraded one of the REMOTE sites to 2.5.2, they stop working! Configs exactly the same. I did FRESH installs of 2.5.2, then simply had the new install grab my backup config file off of USB.
So this must have something to do with the CLIENT side of OPENVPN if the SERVER side updates to 2.5 without issue.
I will also note that the new install in the remote location would not allow any access to the internet either, so its like DNS or something is broken as well. ???
Any update or ideas on any fix would be appreciated.
Thanks,
MP
-
As asked about above make sure the incoming traffic is actually opening states. Check the packet counters on the WAN firewall rule(s). Check the state table.
One thing that can present as seen here is this: https://redmine.pfsense.org/issues/11545
If you have VIPs on WAN go to Status > Interfaces and make sure the WAN is actually using the correct IP. If it isn't go to Interfaces > WAN and resave it.If your OpenVPN server is set to listen on WAN address that bug will break it if you hit it.
Steve
-
@mrpushner Hi MP:
No updates on this yet.
This is on my list for beginning of the year projects.
I have a number of small business PFS 2.4.5 VPN servers deployed.
Some are IPSEC site-to-site.
And others are OpenVPN servers with mobile client users.
All are very simple setups, what I would call "nearly textbook".
Nothing special and nearly default wizard type setups without anything special or unique
other than the specific public IPs involved and pre-shared keys.
I have determined that none of them can be upgraded in place as per my previous posts.
I've also done some troubleshooting and really not made any progress yet.
I've checked and double checked the firewall rules performed packet captures, looked at logs-
I see packets coming in but do not see the vpn servers responding to them per the logs.
I've tried completely deleting all VPN configs (from the GUI) rebooting and re-creating them and recreating others for test, none of which worked.
I've tried manually creating the IPSEC firewall inbound allow rules even though the documentation states these rules are created automatically and are hidden when you
Create an IPSEC config from the GUI because I have read in some posts that people stated they needed to do this.The only things (my next steps) I have not yet tried are
- Posting detailed packet captures and logs here one step at a time and trying to get help.
- Installing TWO clean 2.5.2 systems and trying to bring up a VPN connection between them.
I have a number of non-critical "friend and family" PFSense systems that I have upgraded to
2.5.2 and all of them have lost VPN functionality.
I would really like to both get those back working again and to get all of my business customers up to date
that are on 2.4.5
I also have a new customer that is waiting on me to deploy a VPN server for them.
They are currently on 2.4.5
And I don't want to do this new VPN on 2.4.5 knowing they need to upgrade soon
and that it will break when they do.
Fresh installing 2.5.2 and having to manually build out all of the stuff that has been done on their existing setup would be a lot of work.
So I will indeed be digging in and figuring this out soon.Let's keep in touch on this one MP!
Steve
-
None of them with multiple IPs on WAN? VIPs?
The only other thing that occasionally causes a problem is that with pfSense 2.5 came (confusingly!) an update to OpenVPN 2.5. That has options that are not compatible with earlier clients but it is backwards compatible when upgraded. If you have 2.4 clients connecting though and are exporting new configs be sure to check:
Legacy Client: Do not include OpenVPN 2.5 settings in the client configuration.Steve
-
@n8lbv N8, I never knew this was quite the issue that it really is as I'm finding more thread on this problem.
And I will let you know here if I find out anything new.
Just so you know how mine are currently setup.
I have both PEER and Remote VPN'S setup. I have 3 different physical locations with the Servers all setup in one location, then 2 peer clients, and two remote clients.
I upgraded the server location to 2.5.2. ALL VPN's still worked.
If I update a Peer client, they fail. So VPN SERVER at 2.5.2 and 2.4.4 Peer Clients works, 2.5.2 Server to 2.5.2 clients peer VPN's fail.
I have quickly perused the logs but get impatient as I don't even know what I'm looking for, lol.
I did not try all you did yet. My next step is to remove a peer client that is not working, and recreate it fresh, apply the key, and see what happens.
If that does not work I will fresh Server and Client on each and see if that does anything. Based on what you just said you did, I will not hold my breath that its going to work however.
SIDE NOTE: How do you guys do dev testing of multiple PF boxes from the same Lan/Wan so as to be able to TEST the VPN's without having to have a different actual WAN setup? Is that even possible? (I currently take them home to test)
MP
-
@stephenw10 Hi, yes I did see this in another thread, but then my VPN's setup as REMOTES are still working ok. Its only my PEER VPN's that have failed with the upgrades.
No, I'm not using multiple WAN or Virtual IP's in my setups.
I will note that my PF boxes that are failing ALSO are losing all internet access as well. Can't even ping 8.8.8.8 from the PF box.
That may be another issue and I'm going to double check my DNS and Gateway routing to see if something is a miss there.
Will let you know what I may find.
Thanks,
MP
-
@stephenw10 Thanks, I will check into this first.
-
@mrpushner said in PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?:
but then my VPN's setup as REMOTES are still working ok. Its only my PEER VPN's that have failed with the upgrades.
Can you define exactly what you're referring to there?
Servers vs clients?
SSL/TLS vs PSK?
If one of them is losing connectivity entirely I wouldn't expect VPNs to work.
You see any errors logged at either end?
Steve
-
@stephenw10 Steve, With OpenVPN in PFS there are two types of vpn server mode setup. PEER to PEER (Server - client) or REMOTE ACCESS from the GUI.
When you use the PEER TO PEER, it is literally a VPN from one PFS box to another PFS box say for a VPN between two offices sites, that are on different subnets.
With the REMOTE ACCESS setup, you setup the SERVER on PFS and then use the REMOTE CLIENT wizard to create the OPENVPN "install" file to use on individual remote PC's or say laptops and such to create a VPN for your remote users.
In my case, the REMOTE VPN's are working with the updates to 2.5.2, but the PEER setups (PFS to PFS VPN's) are failing.
I will be reviewing the logs this evening to see exactly what I am getting in the logs.
MP
-
Ok, I see what you're saying.
So all the servers setup as Remote Access and still accessible from whatever the clients are there but the Site-to-Site tunnels are failing.
Behind the scenes the differences are much more subtle, OpenVPN really only operates as client or server with variations. But the big difference here is that in a Peer to Peer VPN using preshared key both sides are configured separately and have to match. Where as in a remote access server using SSL/TLS the clients pull a lot of their config from the server when they connect. So if you update the server end and something changes the clients may pull that change and be able to connect.
So look at the server end of the site to site tunnel in the OpenVPN logs and check for errors.
Check the config between each end. It's possible you were using a weak encryption that was removed for security purposes for example.
Steve
-
@stephenw10 Steve, I am going to do just as you mentioned with the logs and checking encryption.
Are you aware of some way to test VPN's from the same LAN? I want to test these in my office, but I'm already behind the Server PFS box. Is it possible to mask the other PFS boxes and test the VPN's on the same LAN/Wan setup?
Running out to remote sites is a bit annoying when I'm just trying to test these.
Thanks,
MP
-
Sure you can connect locally. The server end doesn't care as long as the credentials match.
You should disable the pass rule on WAN so that the real remote clients isn't also trying to connect at the same time. Otherwise the logs will be much harder to read.Are you seeing this after updating the server or the client end to 2.5.2? Or does either break it?
Steve
-
@stephenw10 Hi, but for the VPN, its expecting to use a WAN IP (and gateway) to make the connection. If I connect my 2nd PFS box to the LAN behind my existing PFS Box, how will it know what to negotiate for its WAN settings?
I can't leave the WAN setting blank on the 2nd PFS box can I? The 2nd box needs to know what gateway to use for internet connectivity as well. I can't give the 2nd box the same WAN settings as my primary PFS box or it will try to act like the "primary firewall" as well, right?
I know I tried this before and could not get it to work. I am missing something.
MP
-
The pfSense box running the client will still connect to the server using the server's public WAN IP. It will just do it from the inside.
I would set the client box up to use DHCP on it's WAN so it just pulls a lease from the main pfSense box like any other LAN side client. Obviously it will need to use a different subnet on it;s LAN to avoid a conflict but that would be true across the VPN anyway.Steve
-
@stephenw10 Steve, BOOM! It worked! I had to change the GATEWAY under SYSTEM-ROUTING to the new gateway created as WAN_DHCP to default as well before it would allow any traffic. (not sure why I did not think to just set the WAN to DHCP, but I believe I did try a different LAN static IP and it did not work)
Now for my VPN updates.
I went in the NEW 2.5.2 install that had the broken peer VPN. I saw that it had a bunch of Data Encryption Algorithms listed there under the Cryptographic Settings section that were NOT listed in the Client setup of the old 2.4.4 install that was still working. I removed them all except the one that showed in the old install and saved.
BOOM! The VPN came back up!
Not sure exactly if it was the order or the fact that the others were listed, but it appears to have been my problem as it is now working.
Thanks for the help! I appreciate it!
N8, not sure this helps you or not, as I believe your using the REMOTE VPN's. Maybe try to setup a peer to peer VPN and see it they work between the PFS boxes? This would at least establish that OPENVPN is working in some facet and maybe help you diagnose.
MP
-
@mrpushner Might help me when I dig back into this.
Some good posts here with good info.
All of my setups have either static IPs or a block of static IPs.
Most are single static IP. nothing dynamic involved.
Also most are IPSEC site to site (no mobile clients of any kind).On all of my previous attempts I had completely torn down any existing VPN setups rebooted and tried over again from scratch, and did not work.
I also tried some OPENVPN server/client stuff from scratch (on an upgraded box) after removing/deleting any existing configs but that did not work.
and I did not spent a whole lot of time on it.
Figured I need to resolve the IPSEC site to site stuff first. -
@n8lbv Ok, so you are using the IPSEC VPN's. Ya know, if my memory serves me correctly, I believe I in fact did used to use the PFS IPSEC tunnels, and I switched to OpenVPN, because I believe I had some issues.
Is there any reason you could not use the OPENVPN VPN's?
Here are the differences:
https://www.firewallhardware.it/en/pfsense-and-vpn-differences-and-insights-on-ipsec-and-openvpn-security/
What I like about OPENVPN is the client package. If you need to say setup VPN's for a client who has remote users (using laptops etc. say at Starbucks), you just grab the installer file created from PFS and install on the devices. Works great. So if they are using un-secured wifi, just have them connect to the tunnel to wrap all the traffic up.
Maybe worth a try. Again I do the SITE TO SITE (PFS to PFS boxes as client-server) VPN's between my office locations, and use the REMOTE VPN's for the remote user devices.
MP
