PFSense Release 2.5 + OpenVPN 2.5 broken? Any fixes?
-
@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.
-
Ok, interesting.
So is the server on port 1195 running on the WAN IP dirrectly or a VIP on the WAN?
Or do you mean it has two WANs?The first thing to check here is that the WAN is not coming up at boot on the server end with the wrong IP as the primary address since we know that can happen and it will cause this.
Steve
-
@stephenw10 Directly on the WAN.
And sorry what I meant was two static IPs that are accessible via the WAN.
I am not using the VIP for VPN services.Also this is getting messy as my main VPN server on port 1194 is back to not working at all since that reboot yesterday.
And reapplying the WAN settings is not fixing it this time.I will need some time to get a handle on this.
It's broken in multiple places right now. -
--- Restarted the service for the 1194 server (main) and it works now.
Plenty of weirdness going on here.
Too many variables right now to be useful I realize.
Will try to narrow it down to something simpler than the problem storm it is now. -
Cool, thanks for gathering data.
It still feels like it at least could still be the incorrect primary IP issue.
Though I note some others who were hitting that frequently are no longer in 2.6.Steve
-
@stephenw10 Minor tiny update.
Worked for several weeks then broke.
Connection is not maintaining itself.
At the far end client (PFsense 2.6) same one we have been testing. in this thread-
Status was stopped and local address pending...
Clicked the start button (in the client ipsec status page) and it came back up and is working.
This is in no way configured to stop or timeout like this.
It should always reconnect on its own if it were ever to lose connection for any reason.
Or if the far end client has a power loss or restart.Serverside is battery backed has continuous uptime, not been restarted since my last email
concerning this project.I feel more like I do now.
-
@n8lbv ```
ar 2 04:08:39 openvpn 33449 Peer Connection Initiated with [AF_INET]S.S.S.S:1195
Mar 2 04:08:40 openvpn 33449 Initialization Sequence Completed
Mar 17 08:40:05 openvpn 33449 write UDPv4: No route to host (code=65)
Mar 17 08:40:15 openvpn 33449 write UDPv4: No route to host (code=65)
Mar 17 08:40:25 openvpn 33449 write UDPv4: No route to host (code=65)
Mar 17 08:40:35 openvpn 33449 write UDPv4: No route to host (code=65)
Mar 17 08:40:46 openvpn 33449 write UDPv4: No route to host (code=65)
Mar 17 08:40:49 openvpn 33449 Inactivity timeout (--ping-restart), restarting
Mar 17 08:40:49 openvpn 33449 SIGUSR1[soft,ping-restart] received, process restarting
Mar 17 08:40:54 openvpn 33449 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 17 08:40:54 openvpn 33449 Re-using pre-shared static key
Mar 17 08:40:54 openvpn 33449 Preserving previous TUN/TAP instance: ovpnc1
Mar 17 08:40:54 openvpn 33449 TCP/UDP: Preserving recently used remote address: [AF_INET]P.P.P.P:1195
Mar 17 08:40:54 openvpn 33449 TCP/UDP: Socket bind failed on local address [AF_INET]C.C.C.C:0: Can't assign requested address (errno=49)
Mar 17 08:40:54 openvpn 33449 Exiting due to fatal error
Mar 17 08:40:54 openvpn 33449 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1572 44.11.11.2 44.11.11.1 init
