PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@stephenw10 This is cool that I got it working now.
I have a number on non-critical "friend and family" sites where VPN has been IPOP since
upgrading past 2.4.5 around Feb. 2020
And I kept customer production systems that needed VPN functionality on 2.4.5Not exactly sure what you mean by using the VIP because it does not change as the WAN address in any of my cases do not change either :) and have never changed.
But yes!
-
The bug here is that when you have VIPs defined on an interface the primary IP address should always be that defined in the interface config and VIP listed below that in the ifconfig output.
But under some unknown conditions ifconfig can start returning one of the VIP addresses at the too if the list. You can check it by running ifconfig manually or on the Status > Interfaces page where the IP address shown is what ifconfig returns.
That means that services using 'WAN address' can end up using a VIP address instead and clients are still using the correct address > failure!
If you set the VPN to use a VIP address instead of the main WAN it will always be that IP even if you hit this bug. But that means either changing the clients to use the VIP address or swapping the main interface and VIP IPs. That may not be practical in some setups.Steve
-
@stephenw10 Cool!
I'm still not quite over the shock and thrill that it's working again :)
Did without it for quite a long time and poked at it here & there over that time. -
@stephenw10 said in PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?:
If you set the VPN to use a VIP address instead of the main WAN it will always be that IP even if you hit this bug. But that means either changing the clients to use the VIP address or swapping the main interface and VIP IPs. That may not be practical in some setups.
Or bind to localhost and use port forward in on WAN port to the instance on localhost.
Or bind to all interfaces/multihome and control access with rules.
Only real reason to bind to a specific interface would be on a client if it had to source from a specific address, but even that is of questionable use these days.
-
Yup that^. Works well for OpenVPN.
-
N N8LBV referenced this topic on
-
N N8LBV referenced this topic on
-
N N8LBV referenced this topic on
-
This will be a topic for another thread, I had the problem "come back"
After I had tried to create an additional site to site shared key openvpn server on a different port.
I was able to get the tunnel to come up and work between the two PFSense systems,
I could ping and reach hosts on both LANS local and remote. (from either PFSense box)
I setup the remote site as a client.
But I could not get any traffic from one LAN to the other (not being routed fully to the other LAN).
I checked and double checked all of my firewall settings and have the usual "allow all to pass" type rules in place on the openvpn interfaces on each pfsense system-
And the routing tables look good on both systems local and remote.
And I can reach both openvpn interface addresses from both LANs so some routing is occurring
part way though at least to the far end openvpn interface.
Anyhow that's not working as planned or expected and it's weird.
I also tried a packet capture on the openvpn interface at the far end while trying to ping a host on the far end LAN, and did not see any traffic here.
The packets originate of the local LAN and are destined to the far end LAN,
I have all of the usual and expected stuff in place, LAN to any rule on both ends etc.
Routing table firewall rules all look proper on both ends and looks like it should work.
reboots made no difference.
I deleted that attempt and was left with my main VPN server on 1194 not responding again until I re-did the save WAN interface settings trick. -
That sounds like it must be a routing issue. Do you have policy based routing that might be overriding the routes added for OpenVPN?
-
@stephenw10 1- I don't think so. 2- I don't think so because I'm not familiar with policy based routing. I will attempt to get familiar.
-
@stephenw10 I did also do a packet capture on the WAN interface /gateway while trying to ping a host on the far end LAN just to confirm it was not taking the default route to the Internet and it was not seen there either.
-
@n8lbv ok did same test with openvpn and routes removed, and I'd expect to see these packets appear on my WAN interface and they are not..
Something's up.
I have something somewhere going on here. I'll find it. -
@n8lbv OK I had an old IPSEC config still stuck in there from testing a week ago that I thought I deleted which involved the same distant LAN subnet.
Nice!Sorry to waste anyone's time here.
But I guess I did figure out that the original 'problem' can come back while messing with openvpn changes, additions & changes.LOL
-
And that remote subnet is now back and working :)
Along with my "main" server for dynamic client devices.
Life isn't so bad. -
@n8lbv said in PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?:
Life isn't so bad.
There are much worse things that can happen!
Still it would be very nice to get that bug squashed. The primary IP address should not change like that.
Steve
-
@stephenw10 Do you figure it's fixed in 2.6?
-
It might have been fixed by something that was pulled in but there has not been anything actively applied to fix it. Unfortunately since I still can't replicate it here I've been unable to test that.
Steve
-
@stephenw10 This is probably a new thread and at this point is just for entertainment.
I updated one simple client site to 2.6.0 and sure enough openvpn back to a 2.5.2 server site is now broken since the update.I have everything working everywhere now with 2.5.2
I thought I try updating one site to 2.6 and boom.
Was confident that it was just going to 'work'.
Nope. :)I've not looked any further into it yet.
Other than reboots restarts etc do not fix it.
And everything at the immediate surface looks like it should be working. -
@n8lbv I had to restart the service on the server side..
There is something wierd going on if it loses connection from the client, the service dies
and never ever restarts on it's own.
I noticed this in 2.5.2 as well
It's an issue that I have not addressed yet.
So false alarm on 2.6.0 there. but the other issue persists.
While I was updating the remote site to 2.6 it was down "long enough" to case the issue to happen.
Causes the server to say that the service is not running on it.
As soon as I restart it on the server it comes back and is ok. -
@n8lbv I will also further note that I am new with using OPENVPN for anything site to site.
I used to always use IPSEC.
So I have some unfamiliarity along with this server stopping issue when the connection is lost or breaks. -
Hmm, sort of sounds like this: https://redmine.pfsense.org/issues/12102
But that's specifically fixed in 2.6.
Check the server side logs for why it shutdown. I wonder if that option is somehow still present in your setup though.Steve
-
@stephenw10 I upgraded the server side of things today to 2.6.0
Before the upgrade I did the traditional remove any packages and restart before upgrading.
only package I had installed with OpenVPN client export.
After the reboot, the vpn client connection was no longer working.
Tried restarting services on both server and client system to no avail-
connection would not come back up.
Went ahead and completed the 2.6.0 upgrade and reboot on the server side.
(client was already upgraded to 2.6.0) a day ago as mentioned in my previous post.
Working VPN connection did not come back.
Tried restarting services and systems again which did not work.
The only thing that worked and worked instantly was re-applying and saving the WAN settings page without making any changes.
Note: This was on the CLIENT end! and not the server.
Single IP on the WAN and it is dynamically (DHCP) configured from the Internet provider.
I will keep tabs on this and experiment to see if I can reliably get it to fail or re-create the problem.
All along I have only expected that problem to be on the server end where it has multiple static IP V4 addresses.
