Project

General

Profile

Actions

Bug #2582

closed

OpenVPN service won't start after changing the IP of interface

Added by ahshang ang over 11 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/07/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

OpenVPN service won't start after changing the IP of interface using by OpenVPN server.

The system log shown that the service try to bind socket on previous IP but failed.
The only way i know in order to solve the issue is restart the pfSense box.

Log details:
openvpn26255: OpenVPN 2.2.0 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011
openvpn26255: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
openvpn26255: TCP/UDP: Socket bind failed on local address [AF_INET]{prevous IP here}:1194: Can't assign requested address
openvpn26255: Exiting

Actions #1

Updated by Chris Buechler over 11 years ago

  • Status changed from New to Feedback

that definitely works in stable releases, looks from that like you're running a snapshot. upgrade to 2.0.1

Actions #2

Updated by ahshang ang over 11 years ago

hi Chris, i am using the latest version. another way is update the "local ip address" in /var/etc/openvpn/server1.conf file manually through shell.
I am not sure whether if the IP address of the "local" variable should auto updated according to the interface change as there is no option for user to change the "local" variable through the web interface.

Actions #3

Updated by Chris Buechler over 11 years ago

what type of WAN?

Actions #4

Updated by ahshang ang over 11 years ago

Any type

Actions #5

Updated by Chris Buechler over 11 years ago

I know that's not true, lots of dynamic WANs out there running OpenVPN that update correctly. What exactly are you doing to replicate?

Actions #6

Updated by ahshang ang over 11 years ago

Below is the steps to replicate the issue:
1) Assign an IP address to a WAN interface.
2) Create a OpenVPN server and select the WAN interface as its interface.
3) Assign an new IP address to the WAN interface.
4) Stop and Start the OpenVPN service through web page.
5) System log will show the error i mentioned earlier. The "local" variable in server1.conf still keeping the previous IP address.

Actions #7

Updated by Mike Noordermeer over 11 years ago

In addition to this, it seems that the interface selection does not work with virtual IPs at the moment (it still assigns the default interface IP and not the virtual IP). This did work in 2.0.1 and in earlier 2.1 snapshots.

Actions #8

Updated by Tyler Merrill over 11 years ago

I also had this same issue, although I'm using 2.0.1 AMD64 release on a virtual machine under VMWare ESXi 5.0.0. We recently changed static blocks and had to reassign interfaces. Our peer-to-peer OpenVPN server services updated fine after a reboot but I had to manually change the server .conf file for our remote access OpenVPN server service. This was not on the primary WAN interface, we use a secondary for remote access. We have 4 total, with the remote access server being the only one that had issues.

Actions #9

Updated by Tyler Merrill over 11 years ago

I should clarify. We have 4 OpenVPN server instances total on this particular pfSense box, with the remote access server service being the only one that did not update it's local IP.

Actions #10

Updated by Phillip Davis over 11 years ago

I just changed my WAN on a test system from DHCP (which had 192.168.9.101 at the time) to a static IP (192.168.9.99) and added the gateway (192.168.9.1) (this test system is hanging off my home router, whose LAN is 192.168.9.0/24). An OpenVPN client that was up, went down. /var/etc/openvpn/client1.conf still had the line:

local 192.168.9.101

Both my servern.conf files also still had this line.
I go to each client and server OpenVPN entry, edit and save. This rewrites the conf file, which now has:
local 192.168.9.99

The OpenVPN client came up straight away.
Then I change my static IP from 192.168.9.99 to 192.168.9.98 - same problem, the OpenVPN conf files are not updated. Need to edit+save them all so they have up-to-date "local" lines in them. I get messages in the logs:
Oct 5 18:39:20     openvpn[60557]: Inactivity timeout (--ping-restart), restarting
Oct 5 18:39:20     openvpn[60557]: SIGUSR1[soft,ping-restart] received, process restarting
Oct 5 18:39:22     openvpn[60557]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 5 18:39:22     openvpn[60557]: Re-using pre-shared static key
Oct 5 18:39:22     openvpn[60557]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.9.99: Can't assign requested address
Oct 5 18:39:22     openvpn[60557]: Exiting
Oct 5 18:39:22     openvpn[60557]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1560 10.9.1.2 10.9.1.1 init

There needs to be some code that re-saves all the OpenVPN conf files when the address of the interface that they are using is manually edited. I guess this is happening already when the interface address changes due to a different DHCP address being given, so it shouldn't be difficult to do the same thing from the manual Interfaces editing GUI.

Actions #11

Updated by Tyler Merrill over 11 years ago

Update to my original issue. After editing the /var/etc/openvpn/server1.conf file with a the new IP everything worked until... a reboot. I now have two "local" entries. One with the new IP and one with the original IP. Of course the service fails with both of these entries in there. Where else are these static IPs saved?

Actions #12

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Closed

this works as it should in 2.1.5 and 2.2

Actions #13

Updated by Jan SH almost 9 years ago

I was running into this when selecting a Failover Gateway Group as the outbound device for the OpenVPN connection, running on latest 2.2.2.

Happy to perform any steps/checks to help you guys reproduce...

Actions

Also available in: Atom PDF