PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?

mrpushner

@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

N8LBV

@stephenw10 Thanks, I will check into this first.

stephenw10

@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

mrpushner

@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

stephenw10

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

mrpushner

@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

stephenw10

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

mrpushner

@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

stephenw10

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

mrpushner

@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

N8LBV

@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.

mrpushner

@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

N8LBV

@mrpushner The reason for not using OPENVPN for some of the site to site is 1. I've never done that yet. and 2. some of the IPSEC tunnels are from PFSense to some other non-PFSense IPSEC device such as Cisco etc.
When I first started using PFSense awhile back- most sites were using Cisco.
And I still have a few that are on one end.

N8LBV

I brought up a fresh clean 2.5.2 box.
Messed around for a couple of hours trying to get a basic OPENVPN server to work with a windows OPENVPN client.

It is not working out of the box.
I have done this type of simple setup many times with 2.4.5 and never had any issues getting a simple tunnel from a windows client back to a PFSense OPENVPN server to work.

Pretty much going with the default settings on an OPENVPN server and taking all of the encryption settings that it suggests out of the box.

Not been able to get a connection to work with 2.5.2 yet ever.

Fri Jan 14 17:36:54 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]n.n.n.n:1194
Fri Jan 14 17:36:54 2022 UDPv4 link local (bound): [AF_INET][undef]:1194
Fri Jan 14 17:36:54 2022 UDPv4 link remote: [AF_INET]n.n.n.n:1194
Fri Jan 14 17:37:54 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

If I install 2.4.5 and try a similar VPN tunnel, it works fine.

It acts like the server is just flat out not listening or responding to anything.
OPENVPN log on PFSense shows nothing like it's just braindead.
Same if I try to connect openVPN client to it from the LAN or from outside (public IP).

Pretty frustrating.
It's behaving exactly like PFsense 2.5.0 did for me a year ago.
I've been unable to get a simple OPENVPN tunnel or an IPSEC site to site tunnel to work.
And pretty much why I quickly gave up a year ago.

Same windows client testing here connects to a remote site on PFsense 2.4.5 just fine.

Firewall rule allowing UDP 1194 from any is in place.

I do a packet capture on the WAN- I see the UDP 1194 packets coming and no responses.

18:08:52.573612 IP 174.211.0.241.6996 > n.n.n.n.1194: UDP, length 54
18:08:54.624030 IP 174.211.0.241.6996 > n.n.n.n.1194: UDP, length 54

N8LBV

Got it fixed.
Stupid typo in one of the subnets.

Will try some IPSEC soon.

Jan 14 17:21:47 openvpn 12108 Options error: --server directive network/netmask combination is invalid

stephenw10

Do you see states opened on port 1194? If not do you see blocks in the firewall log?

Did you export the Windows client from 2.5.2? If not what version is the client?

I would still expect to see some log entries at the server end even if it rejects the connection unless the traffic is not actually reaching it.

I've setup numerous OpenVPN servers in 2.5.X and not seen any issues as long as the client is using the same OpenVPN version. Confusingly that is also 2.5.
If the client and server are using different versions you need to be careful to use compatible settings.
If it's a really old client it might be using something deprecated that the server rejects. I don't think that's the case though since it's not logging anything.

Steve

N8LBV

Still completely broken on any system that has been updated from 2.4.5 regardless of clearing out all VPN configs and trying to recreate them.
What I got working above on my last response was a clean install out of the box of 2.5.2

So I will need to get back to troubleshooting on those systems.

stephenw10

Mmm, gonna need more data to troubleshoot that further. There must be something specific in your config though.

N8LBV

@stephenw10 Realize this :)
I will get at it soon.

There seem to be a number of posts about it, I've went thought them in the past and will need to do it again.

N8LBV

Not sure if this is a clue. System still acts braindead, nothing is logged when attempting a client connection, Upon startup I see the following as the only clue something might be wrong.
I have tried completey wiping ALL vpn configs and certificates from scratch
and created a new OPENSEC VPN server. and client.

Jan 28 14:17:51	openvpn	39698	Initialization Sequence Completed
Jan 28 14:17:51	openvpn	39698	UDPv4 link remote: [AF_UNSPEC]
Jan 28 14:17:51	openvpn	39698	UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Jan 28 14:17:51	openvpn	39698	/usr/local/sbin/ovpn-linkup ovpns1 1500 1621 44.44.73.1 255.255.255.0 init
Jan 28 14:17:51	openvpn	39698	/sbin/ifconfig ovpns1 44.44.73.1 44.44.73.2 mtu 1500 netmask 255.255.255.0 up
Jan 28 14:17:51	openvpn	39698	ioctl(TUNSIFMODE): Device busy (errno=16)
Jan 28 14:17:51	openvpn	39698	TUN/TAP device /dev/tun1 opened
Jan 28 14:17:51	openvpn	39698	TUN/TAP device ovpns1 exists previously, keep at program end