Project

General

Profile

Actions
Copy link

Bug #2647

closed

rc.newwanip discovers wrong WAN IP when using DHCP

Added by Christoph Filnkößl about 12 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
09/30/2012
Due date:
% Done:

0%

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

Description

It seems that pfSense's rc.newwanip has got problems discovering the right WAN IP after running some time.

We are running our pfSense as described below:
  • 213.0.0.9 as WAN IP - DHCP from provider (always the same address)
  • 212.0.0.16/28 as "IP Alias" Virtual IPs on the WAN interface

When booted, pfSense discovers 213.0.0.9 as it's own IP address - everything running fine.
Some days later dhclient runs successfully, gets the 213.0.0.9 IP but rc.newwanip discovers 212.0.0.19 as its WAN IP.
After that, pfSense only responds under the 212.0.0.19 IP.

read from bottom to top:

Jun 27 03:59:03    apinger: Starting Alarm Pinger, apinger(27639)
Jun 27 03:59:03    check_reload_status: Reloading filter
Jun 27 03:59:02    apinger: Exiting on signal 15.
Jun 27 03:59:01    php: : ROUTING: setting default route to 213.0.0.1
Jun 27 03:59:01    php: : rc.newwanip: on (IP address: 212.0.0.19) (interface: wan) (real interface: vr2).
Jun 27 03:59:01    php: : rc.newwanip: Informational is starting vr2.
Jun 27 03:58:55    dhclient[2348]: bound to 213.0.0.9 -- renewal in 189670 seconds.
Jun 27 03:58:55    check_reload_status: rc.newwanip starting vr2
Jun 27 03:58:55    dhclient: Creating resolv.conf
Jun 27 03:58:55    dhclient: /sbin/route add default 213.0.0.1
Jun 27 03:58:55    dhclient: Adding new routes to interface: vr2
Jun 27 03:58:55    dhclient: New Routers (vr2): 213.0.0.1
Jun 27 03:58:55    dhclient: New Broadcast Address (vr2): 255.255.255.255
Jun 27 03:58:55    dhclient: New Subnet Mask (vr2): 255.255.255.0
Jun 27 03:58:55    dhclient: New IP Address (vr2): 213.0.0.9
Jun 27 03:58:55    dhclient: ifconfig vr2 inet 213.0.0.9 netmask 255.255.255.0 broadcast 255.255.255.255
Jun 27 03:58:55    dhclient: Starting add_new_address()
Jun 27 03:58:55    dhclient: BOUND
Jun 27 03:58:55    dhclient[2348]: DHCPACK from 10.34.114.129
Jun 27 03:58:55    dhclient[2348]: DHCPREQUEST on vr2 to 255.255.255.255 port 67
Jun 27 03:58:55    dhclient: ARPCHECK
Jun 27 03:58:53    dhclient: ARPSEND
Jun 27 03:58:53    dhclient[2348]: DHCPOFFER from 10.34.114.129
Jun 27 03:58:53    dhclient[2348]: DHCPDISCOVER on vr2 to 255.255.255.255 port 67 interval 1
Jun 27 03:58:52    dhclient[2348]: DHCPDISCOVER on vr2 to 255.255.255.255 port 67 interval 1
Jun 27 03:58:52    dhclient[2348]: DHCPNAK from 10.34.114.129
Jun 27 03:58:52    dhclient[2348]: DHCPREQUEST on vr2 to 255.255.255.255 port 67
Jun 27 02:55:10    dhclient[2348]: DHCPREQUEST on vr2 to 10.34.114.129 port 67

Applying WAN interface setting again (no changes) helps and pfSense discovers the right IP.

This happens every 5-15 days and pfSense occupies a random IP from the 212.0.0.16/28 subnet.

Feel free to ask for further details.

Actions
Copy link
 #1

Updated by Jim Pingle about 12 years ago

  • Status changed from New to Feedback

Please try to reproduce this on a 2.1 snapshot. rc.newwanip and the dhclient-script have been changed quite a bit on 2.1, so unless this issue can be repeated there, we can't really investigate it properly.

Actions
Copy link
 #2

Updated by Christoph Filnkößl almost 12 years ago

long time no see.

updated to 2.1-BETA1 (i386) - built on Sun Jan 27 20:33:23 EST 2013
we have still got the same problem

it seems that rc.newwanip discovers the wrong IP whereas dhclient has got the right one.

Feb 10 10:52:07    kernel: pid 60560 (php), uid 0, was killed: out of swap space
Feb 10 10:52:07    php: : pfSense package system has detected an ip change -> ... Restarting packages.
Feb 10 10:52:07    check_reload_status: Reloading filter
Feb 10 10:52:07    php: : rc.newwanip: on (IP address: 10.12.10.1) (interface: ) (real interface: ovpns1).
Feb 10 10:52:07    php: : rc.newwanip: Informational is starting ovpns1.
Feb 10 10:52:07    php: : Restarting/Starting all packages.
Feb 10 10:51:59    check_reload_status: rc.newwanip starting ovpns1
Feb 10 10:51:58    kernel: ovpns1: link state changed to UP
Feb 10 10:51:58    check_reload_status: Starting packages
Feb 10 10:51:58    php: : pfSense package system has detected an ip change 213.0.0.9 -> ... Restarting packages.
Feb 10 10:51:58    php: : Creating rrd update script
Feb 10 10:51:58    kernel: ovpns1: link state changed to DOWN
Feb 10 10:51:57    php: : Resyncing OpenVPN instances for interface WAN.
Feb 10 10:51:51    php: : phpDynDNS (something.no-ip.info): (Success) DNS hostname update successful.
Feb 10 10:51:51    php: : phpDynDNS: updating cache file /conf/dyndns_wannoip'something.no-ip.info'0.cache: 212.0.0.19
Feb 10 10:51:51    php: : DynDns debug information (something.no-ip.info): 212.0.0.19 extracted from local system.
Feb 10 10:51:51    php: : DynDNS (something.no-ip.info): Current Service: noip
Feb 10 10:51:51    php: : DynDNS (something.no-ip.info): DynDns _checkStatus() starting.
Feb 10 10:51:50    php: : DynDNS (something.no-ip.info): DynDns _update() starting.
Feb 10 10:51:50    php: : DynDns debug information (something.no-ip.info): DynDns: cacheIP != wan_ip. Updating. Cached IP: 213.0.0.9 WAN IP: 212.0.0.19
Feb 10 10:51:50    php: : DynDns (something.no-ip.info): Current WAN IP: 212.0.0.19 Cached IP: 213.0.0.9
Feb 10 10:51:50    php: : DynDns debug information (something.no-ip.info): 212.0.0.19 extracted from local system.
Feb 10 10:51:50    php: : DynDNS (something.no-ip.info): running get_failover_interface for wan. found vr2
Feb 10 10:51:50    php: : DynDns debug information (something.no-ip.info): 212.0.0.19 extracted from local system.
Feb 10 10:51:50    php: : DynDns: updatedns() starting
Feb 10 10:51:50    check_reload_status: Reloading filter
Feb 10 10:51:49    php: : ROUTING: setting default route to 213.0.0.1
Feb 10 10:51:46    php: : rc.newwanip: on (IP address: 212.0.0.19) (interface: wan) (real interface: vr2).
Feb 10 10:51:46    php: : rc.newwanip: Informational is starting vr2.
Feb 10 10:51:42    dhclient[20345]: bound to 213.0.0.9 -- renewal in 196527 seconds.
Feb 10 10:51:41    check_reload_status: rc.newwanip starting vr2
Feb 10 10:51:41    dhclient: Creating resolv.conf
Feb 10 10:51:41    dhclient: /sbin/route add default 213.0.0.1
Feb 10 10:51:41    dhclient: Adding new routes to interface: vr2
Feb 10 10:51:41    dhclient: New Routers (vr2): 213.0.0.1
Feb 10 10:51:41    dhclient: New Broadcast Address (vr2): 255.255.255.255
Feb 10 10:51:41    dhclient: New Subnet Mask (vr2): 255.255.255.0
Feb 10 10:51:41    dhclient: New IP Address (vr2): 213.0.0.9
Feb 10 10:51:41    dhclient: ifconfig vr2 inet 213.0.0.9 netmask 255.255.255.0 broadcast 255.255.255.255
Feb 10 10:51:41    dhclient: Starting add_new_address()
Feb 10 10:51:41    dhclient: Removing states through old gateway '' (new gateway '213.0.0.1')
Feb 10 10:51:41    dhclient: Comparing Routers: Old: New: 213.0.0.1
Feb 10 10:51:41    dhclient: Comparing IPs: Old: New: 213.0.0.9
Feb 10 10:51:41    dhclient: Starting delete_old_states()
Feb 10 10:51:41    dhclient: BOUND
Feb 10 10:51:41    dhclient[20345]: DHCPACK from 10.34.114.129
Feb 10 10:51:41    dhclient[20345]: DHCPREQUEST on vr2 to 255.255.255.255 port 67
Feb 10 10:51:41    dhclient: ARPCHECK
Feb 10 10:51:39    dhclient: ARPSEND
Feb 10 10:51:39    dhclient[20345]: DHCPOFFER from 10.34.114.129
Feb 10 10:51:39    dhclient[20345]: DHCPDISCOVER on vr2 to 255.255.255.255 port 67 interval 1
Feb 10 10:51:38    dhclient[20345]: DHCPDISCOVER on vr2 to 255.255.255.255 port 67 interval 1
Feb 10 10:51:38    dhclient[20345]: DHCPNAK from 10.34.114.129
Feb 10 10:51:38    dhclient[20345]: DHCPREQUEST on vr2 to 255.255.255.255 port 67
Feb 10 10:51:07    dhclient[20345]: DHCPREQUEST on vr2 to 10.34.114.129 port 67
[DHCPREQUEST around once per minute]
Feb 10 01:01:05    dhclient[20345]: DHCPREQUEST on vr2 to 10.34.114.129 port 67
Actions
Copy link
 #3

Updated by Christoph Filnkößl almost 12 years ago

Could you help us here?
pfSense is loosing connectivity completely now and then.

Please tell me if there's anything we can do to help fix this bug.

Actions
Copy link
 #4

Updated by Christoph Filnkößl almost 12 years ago

ok, I tried to find the bug myself.
As we need to use DHCP on WAN (Cable Source-Verify) the address is being renewed from time to time.
When this happens, dhclient assigns the IP to the WAN interface.

everything normal after boot or re-applying interface settings:

[2.1-BETA1][christoph@something.at]/home/christoph(6): ifconfig vr2
vr2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
    ether 00:0d:b9:24:d8:0a
    inet6 fe80::20d:b9ff:fe24:d80a%vr2 prefixlen 64 scopeid 0x3 
    inet 213.0.0.9 netmask 0xffffff00 broadcast 255.255.255.255
    inet 212.0.0.19 netmask 0xfffffff0 broadcast 212.0.0.31
    inet 212.0.0.20 netmask 0xfffffff0 broadcast 212.0.0.31
    [...]
    nd6 options=1<PERFORMNUD>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active

pfSense_get_interface_addresses(vr2) works fine:

["ipaddr"]=>string(9) "213.0.0.9"

after dhclient runs:

[2.1-BETA1][christoph@something.at]/home/christoph(6): ifconfig vr2
vr2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
    ether 00:0d:b9:24:d8:0a
    inet6 fe80::20d:b9ff:fe24:d80a%vr2 prefixlen 64 scopeid 0x3 
    inet 212.0.0.19 netmask 0xfffffff0 broadcast 212.0.0.31
    inet 212.0.0.20 netmask 0xfffffff0 broadcast 212.0.0.31
    [...]
    inet 213.0.0.9 netmask 0xffffff00 broadcast 255.255.255.255
    nd6 options=1<PERFORMNUD>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active

after that, pfSense_get_interface_addresses(vr2) discovers the wrong address as it takes the first IP:

["ipaddr"]=>string(10) "212.0.0.19"

The problem seems to be that pfSense_get_interface_addresses() simply takes the first IP, even if it's a virtual IP.
Is there a way to fix this behavior?

Actions
Copy link
 #5

Updated by Jim Pingle almost 12 years ago

Have you tried this on 2.1, as recommended? Quite a lot of work went into fixing these kinds of bugs there. Specifically there was already a ticket open about the wrong IP being used when there was an IP alias IP on the interface, which has been fixed for several weeks on 2.1.

Actions
Copy link
 #6

Updated by Christoph Filnkößl almost 12 years ago

Yeah, I tried this on 2.1 from March 7th and January 27th.
Please tell me if you need more information.

Actions
Copy link
 #7

Updated by Jim Pingle almost 12 years ago

It was fixed on Jan 31, See #2495 - if it's still broken on 2.1 using a current snapshot, reply there, since that's actually the correct ticket for the issue.

Actions
Copy link
 #8

Updated by Chris Buechler almost 12 years ago

  • Status changed from Feedback to Closed

duplicate of #2495

Actions
Copy link

Also available in: Atom PDF