OpenVPN died when PPPOE link came up with a different IP.
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.)
Ticket #449. Teach OpenVPN to reload only tunnels for the specified interface. Use this is rc.newwanip script to reload only these tunnels.
Ticket #449. Bring back the check if there is really an ip change on interface event. This avoids reloading openvpn and other sevices when actually there is no change.
#6 Updated by Chris Buechler about 10 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.
#9 Updated by Jim Pingle about 10 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.
#11 Updated by Jim Pingle about 10 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.