Bug #449
closed
OpenVPN died when PPPOE link came up with a different IP.
0%
Description
I have both a OpenVPN client configuration (connecting to a server on the net with a static IP), and an OpenVPN server configuration.
When my PPPOE link dropped and came back up with a different IP, both the openvpn processes stopped. IE: my client connection to the remote server stopped, as well as my openvpn server stopped and didnt restart automatically (I waited about 10 mins). The logs showed this:
Mar 25 11:44:10 openvpn51140: TCP/UDP: Socket bind failed on local address 124.168.x.x:11196: Can't assign requested address
Mar 25 11:44:10 openvpn51140: Exiting
Mar 25 11:44:10 openvpn39460: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 25 11:44:11 openvpn39460: TCP/UDP: Socket bind failed on local address 124.168.x.x:1194: Can't assign requested address
Mar 25 11:44:11 openvpn39460: Exiting
In this case 124.168 was the old address...
Two issues:- Shouldnt the openvpn service restart automatically?
- There is no way to manually restart it. Be nice if it was on the dashboard like ntpd, dhcpd are.)
(A resave of each configuration resulted in the openvpn process restarting. Obviously a reboot would do the same thing - but a little drastic where pfsense is being used on dynamic ip based links.)
Updated by Chris Buechler over 14 years ago
- Target version set to 2.0
Any servers or clients bound to a dynamic interface must be restarted as the 'local ...' specification for binding will change.
Updated by Chris Buechler over 14 years ago
that should say "restarted when the IP changes"
Updated by Deon George over 14 years ago
All good (as of the 1st April snapshot).
Change of WAN IP doesnt stop OpenVPN functioning anymore - thank you :)
Updated by Chris Buechler over 14 years ago
- Status changed from Feedback to Resolved
Updated by Chris Buechler over 14 years ago
- Status changed from Resolved to New
This fix is excessive and causes different problems. It now restarts OpenVPN after every DHCP renewal (and probably PPPoE reconnect, etc.), which in many instances is unnecessary and disrupts connectivity for no reason. When your IP changes, connectivity has to be briefly disrupted so that's fine and unavoidable, but it can't do this when the IP has not changed.
Updated by - BlackB1rd - over 14 years ago
Doesn't seem to restart any longer on DHCP renewal when the IP hasn't changed (snapshot April 28th).
Updated by Jim Pingle over 14 years ago
- Status changed from Feedback to New
I am running last night's snapshot and gitsync'd to current code as of this update.
OpenVPN connections are not being restarted properly on IP change. I've had to restart them by hand several times today as I am testing. It may be handling the case where the IP does not change OK now, but if the IP does change, they aren't being restarted.
Updated by Ermal Luçi over 14 years ago
There might be issues with restarting openvpn.
Maybe a sleep should be introduced somewhere!
Updated by Jim Pingle over 14 years ago
- Status changed from New to Feedback
I found that the OpenVPN client page was not properly testing/setting the disable variable, and it was also not being upgraded properly from 1.2.x to 2.0. This combination made the OpenVPN sync functions that only read the config fail, because to them the tunnels appear disabled. When saved from the GUI, the way it handled the disabled function it worked at the time.
I added upgrade code to fix this (https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/763a1b5225ab38d92295d856ee7c83056ed88b5f) and fixed the OpenVPN client page to fix it also (https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/8319ee6335028d9caa444816498a3dfe4587f430 / https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/b65f56f69baec76614296e393a74deedba13da48)
Not sure if we can make a bit of upgrade code to handle this or not for people already on 2.0. Otherwise you just need to edit/save all client tunnels.