PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@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. -
Hmm, so only one IP on the client side WAN?
Maybe no default route? That gets re-applied by resaving the WAN.
Steve
-
@stephenw10 Yes only one IP (dynamic) and default route existed and worked.
-
Hmm, odd. Does it look like it's trying to connect before resaving?
-
@stephenw10 Yes, just from memory something like "ping timeout retrying"..
But I'm not exactly sure.
Will have to see if I can get it to fail again. -
@n8lbv I'm able to re-create to problem by restarting the server.
If I restart only the client it comes back and connects.
If I restart the server the connection never comes back.
On the client side it says: " reconnecting; ping-restart" under status.Local address and remote host both have "pending".
Saving and applying WAN on the client this time is not fixing it.
Also just tried reapplying wan settings on the server.
And it's not working.
I now have a broken connection that is not working and not sure how to fix since rebooting the server end. -
@n8lbv Some kind of unknown combination of restarting the client and server services
and reapplying the WAN settings finally got it to come back after about ten minutes of trying all four things over & over again.I'll have to work at it and try to narrow it down to something more definitive.
For now - restarting the Pfsense box with the openvpn server on it initiates the problem,
The tunnel does not come back and remains broken until I start fiddling with it as stated above.This box does have TWO static public IPs and two VPN servers, one on port 1194 and another on 1195.
And it's the client connection using 1195 that is failing.
Probably a tad more complicated of a setup than we'd prefer to troubleshoot such a problem.
-
@n8lbv Once the connection is up it works great and is solid and seems to run fine for days.
It gets unhappy when I reboot the server.
And stays unhappy.I'll dig in more over the next few days and try to narrow this down a bit more than what I have presented now which is a bit of a mess.
