PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@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
-
@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. -
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 -
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
-
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
-
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.2So I will need to get back to troubleshooting on those systems.
-
Mmm, gonna need more data to troubleshoot that further. There must be something specific in your config though.
-
@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.
-
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
-
@stephenw10 Yes I see a state for 1194 when attempting a connection:
WAN udp c.c.c.c:1194 -> s.s.s.s:1194 NO_TRAFFIC:SINGLE 3 / 0 246 B / 0 B
c= remote client IP
s= test server IPWith logging enabled for the port 1194 rule I see in the log the packets are being accepted (green checkmark).
Nothing is being blocked.
Nothing is being logged in IPSEC otehr than on startup or IPSEC services restart.
The "braindead" appearance I mention a few times here.
Also this server has more than one public IP available on the WAN interface.
I don't know if this is related to my problem or if it's a factor.
I seem to remember reading something about this being and issue with 2.5.0
But am having difficulty finding it. -
This post is deleted! -
@n8lbv Also if this provides anything useful:
Not sure about the warnings, but same way of setting up a clean install single public IP box works fine.
This box as most I have in the field are multiple public IP on WAN (most only two).
and have been upgraded from pfsense 2.4.5 t0 2.5.2
Every upgraded box I have upgraded has no working VPNs IPSEC or OPENVPN since upgrading.Trying hard to provide mroe logs but almost anything I post is "flagged as spam"
I have spent literally hours trying to figure out how to post and include logs.
Incredibly frustrating!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 Jan 28 14:17:51 openvpn 39698 WARNING: experimental option --capath /var/etc/openvpn/server1/ca Jan 28 14:17:51 openvpn 39698 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jan 28 14:17:51 openvpn 39698 GDG: problem writing to routing socket Jan 28 14:17:51 openvpn 39698 WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want Jan 28 14:17:51 openvpn 35907 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 Jan 28 14:17:51 openvpn 35907 OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 24 2021 Jan 28 14:12:36 openvpn 98001 Initialization Sequence Completed Jan 28 14:12:36 openvpn 98001 UDPv4 link remote: [AF_UNSPEC]
-
@n8lbv Tried a couple of this and there is some more data.
-
@n8lbv This error-
Jan 28 14:17:51 openvpn 39698 ioctl(TUNSIFMODE): Device busy (errno=16)
does not appear to be an issue from reading.
Also I can't find any indication that multiple IP addresses on the WAN should be any issue.When setting up the OVPN server the WAN dropdown list includes both what I am using as a primary WAN IP and my secondary use WAN IP.
It is clear that you can select either for the OVPN server and that I am selecting the one that I want.
This apparently should not be any kind of an issue. -
Nope, that's normal (reversed) logs when the server starts.
Do you see states in the firewall when clients try to connect?
-
@stephenw10 Yes somwhere he posted today I showed that there are states. (replying from my phone browser) at the bar :)
-
@n8lbv When posted earlier :) but yes. states exist!
-
Pretty much clueless and right back to where I started ages ago when 2.5.0 was released.
No clue what to try next and no luck success or further information with all of the normal checks and suggestions.This is why most of my customer sites are still stuck on 2.4.5
VPN guaranteed to break after upgrading.
And doing a fresh install and trying to get all of the individual site config/settings manually reconfigured will not be an easy option for me at all.And pulling over the config backup from a 2.4.5 system after clean installing 2.5.2 has not worked either.
Same issue, VPN functionality ends up like what I have here. braindead.
-
@n8lbv Hi, When you do one of this updates, are you verifying that the Default Gateway is correct in your SYSTEM-ROUTING settings? Can you access the internet ok and ping say 8.8.8.8 from the PFSENSE ping utility?
I was seeing issues with my update to 2.5.2 as well, and my OPEN VPN's were not working.
Turns out that my gateway was messed up in my Routing settings.
However, I could NOT get PFS to update properly with multiple installs from the GUI!
When I did a backup of the 2.4 config then a FRESH install of 2.5.2, with the 2.4 config on the usb drive, it grabbed it and applied all the settings at the end of the install.
Then after it is up, it had to update my packages. (you will get a message at top of PFS about packages will be updated and check back later or such) Well if I remember correctly I believe that at least once even with the fresh install it the package updates crashed PFS. I could not access the GUI even though the firewall was still functioning.
PFS suggests that you DO NOT UPDATE packages before trying a system update and ALSO that you UNINSTALL ALL PACKAGES BEFORE you try to update if you are seeing problems!
Maybe a package is messing you up?
Now I'm not sure how it knows, but when I did this with a package, it still knew and kept all my settings!
Maybe try this. Maybe a package is wrecking your VPN's somehow. And check you Routing (and DNS settings) like mentioned above, make sure PFS is getting out to the internet and getting proper DNS function.
MP
-
@mrpushner Thanks for the reply.
No problems at all with default (and only) gateway settings.
And system works perfectly fine other than I have been unable to get an IPSEC or openVPN server to work on them after upgrading yet ever.
I have tried pretty much everything that I could think of including following the directions and uninstalling all packages before upgrading) then reinstalling packages after upgrading.
--> t\The only package I have installed is the client export package. This was simple and not a lot of work.At this troubleshooting stage I am only testing setting up an OpenVPN Server as to not confuse or complicate matters.
Fact is IPSEC does not work as expected either. But I am trying to keep initial troubleshooting easy here.A simple OPENVPN server (Remote Access SSL/TLS + User Auth) on the server.
And a windows remote client.Pretty much using the default settings that PFSense sets for you when setting this up.
It works on any clean install box with a single public IP (static or dynamic) that I have tested.
It is not working on any of my production systems that have both been upgraded from 2.4.5 to 2.5.2 and have two static public IP addresses configured.
When setting up the server I am clearly selecting the intended "main" public IP I intend to use.
The firewall rules and packet captures and firewall logging all seem to be working as expected.
VPN server seems braindead and nothing is logged when connection attempts are made.
Only logging you see from the openVPN server is when it is started up or manually restarted or when the system is rebooted and the service starts up.