PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@stephenw10 Thanks - I will check into this. Does it only affect or apply to IPSEC?
I am currently only testing/troubleshooting with OPENVPN until I get that working first and then planned to circle back to IPSEC.
Mainly just to keep this less confusing and have more of a single point of focus to work on and troubleshoot, even though I know BOTH are not working on my systems ever since upgrading past 2.4.5 and now currently at 2.5.2 :)Steve
-
@stephenw10 Holy Crap!
That might have effing worked!
I'll get back on this and let you know.
I remember trying this a long long time ago without any luck.
But that would have been combined with old configs carried over versus me trying with new
server certs and tunnels built from scratch after all of the old stuff was deleted.
:) -
Yeah, when you hit that it affects both IPSec and OpenVPN if they are set to listen on 'WAN address'. Some users seem to hit this regularly but I have never managed to replicate it locally and, as far as I know, neither have any of the devs which makes it impossible to pin down.
A possible workaround is to use the VIP address for the VPN because that does not change. That's not suitable for everyone though.
Steve
-
@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.
