PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@gertjan Please don't get stuck in a circle about the too old thing. We all know that 2.4.4 is no longer "supported", no need go on about that too much.
Thanks.All of my systems that I am presenting here were updated to 2.5.0 and 2.5.2 a long time ago.
Fact is -some people are still on 2.4.5 including some of my sites due to the upgrading issues not being fully figured out yet.Also I'm not really inclined to signup for another account on an external system just to post
log snippets here. This forum provides for easily posting inline log snippets or examples.
I did not really understand you "please don't post logs here" comment.
pastebin might be great for some people and if you like it, by all means suggest and promote it.But I don't undertand your asking not to post logs here unless you are talking about
large pieces, pages & pages.
In that case what you are asking makes complete sense.
I try to keep any log postings here short and relevant unless otherwise a full longer log is needed. Thanks! :) -
@n8lbv said in PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?:
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.
This still sounds like what I initially suggested in this thread, this bug:
https://redmine.pfsense.org/issues/11545How do you have the IPs configured if not as VIPs on WAN?
If it is like that then check the WAN interface status and make sure it's using the expected IP address. The symptoms of this are exactly what you're describing.
Steve
-
@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
