Bug #2495
closed
pfsense doesn't seem to know what its WAN IP is
100%
Description
Having upgraded from stable to 2.1-BETA0 (i386) (built on Mon Jun 11 03:04:03 EDT 2012), a strange issue has occurred. The WAN interface IP is configured as 31.24.0.195/26 and there's 3 IP aliases to this interface:
31.24.0.198/32
31.24.0.196/32
31.24.0.200/32
pfsense thinks the WAN interface IP is 31.24.0.196. This shows in a few different ways:
- The IPSec Local IP is 31.24.0.196 - this causes ipsec to break.
- None of the firewall rules permitting access to "WAN address" work - rather they allow access to 31.24.0.196 instead
- I cannot edit the 31.24.0.196 IP alias as it says an alias cannot be the WAN address
Interestingly, changing the WAN IP subnet from /26 to /25 fixes this issue and pfsense correctly identifies its WAN IP. This is what I have put in place, presently, pending a better fix.
Files
| config-pfsense.localdomain-20130806121907.xml (18.7 KB) config-pfsense.localdomain-20130806121907.xml | problematic config.xml | ||
| console_after.png (26.7 KB) console_after.png | console output after adding the alias and rebooting | ||
| console_before.png (27.1 KB) console_before.png | console output before adding the alias | ||
| ifconfig_after.png (92.9 KB) ifconfig_after.png | ifconfig output after adding the alias and rebooting | ||
| ifconfig_after-add-before-reboot.png (92.8 KB) ifconfig_after-add-before-reboot.png | ifconfig after adding the alias but before rebooting | ||
| ifconfig_after-refresh.png (92.4 KB) ifconfig_after-refresh.png | ifconfig after save and apply on br0 infterface configuration | ||
| ifconfig_before.png (90.2 KB) ifconfig_before.png | ifconfig before adding the alias | ||
| interfaces_after.png (46.6 KB) interfaces_after.png | WebGUI Status-Interfaces after adding the alias and rebooting | ||
| interfaces_before.png (46.9 KB) interfaces_before.png | WebGUI Status-Interfaces before adding the alias |
Updated by Corey Quinn almost 12 years ago
I can confirm this; OpenVPN is binding to a random IP that's IP Aliased.
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
- Assignee set to Renato Botelho
I couldn't reproduce it on recent 2.1-BETA1 snapshot. Could you please confirm if it's still happening?
Updated by Phil Lavin over 11 years ago
It's a production router - I'll try to update when most of the populous have gone home and I'll let you know.
Phil
Updated by Jim Pingle over 11 years ago
In the meantime, please show the output of:
ifconfig -a
Feel free to mask the IPs if you like, but leave enough to identify which is the "correct" IP and which are the IP aliases.
Updated by Phil Lavin over 11 years ago
[2.1-BETA0][root@prop-router-rugby.local]/root(1): ifconfig -a
msk0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:95
media: Ethernet autoselect
msk1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:94
media: Ethernet autoselect
msk2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:93
media: Ethernet autoselect
msk3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:92
media: Ethernet autoselect
sk0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80008<VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:91
inet6 fe80::290:7fff:fe3f:cd91%sk0 prefixlen 64 scopeid 0xa
inet 31.24.0.201 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.202 netmask 0xffffffff broadcast 31.24.0.202
inet 31.24.0.195 netmask 0xffffff80 broadcast 31.24.0.255
inet 31.24.0.198 netmask 0xffffffc0 broadcast 31.24.0.255
inet6 2a02:b90:7004::1 prefixlen 50
inet 31.24.0.196 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.200 netmask 0xffffffc0 broadcast 31.24.0.255
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd90%sk1 prefixlen 64 scopeid 0xb
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:8f
inet6 fe80::290:7fff:fe3f:cd8f%sk2 prefixlen 64 scopeid 0xc
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd8e%sk3 prefixlen 64 scopeid 0xd
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (none)
status: no carrier
pflog0: flags=100<PROMISC> metric 0 mtu 33200
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xf
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
sk1_vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd95%sk1_vlan1 prefixlen 64 scopeid 0x12
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2a02:b90:7004:4000:: prefixlen 50
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 1 vlanpcp: 0 parent interface: sk1
sk1_vlan4: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,IPFW_FILTER> metric 0 mtu 1500
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd95%sk1_vlan4 prefixlen 64 scopeid 0x13
inet 10.20.0.1 netmask 0xffffff00 broadcast 10.20.0.255
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 4 vlanpcp: 0 parent interface: sk1
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:0f:75:e7:bc:00
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: sk2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 12 priority 128 path cost 55
member: sk0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 55
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
sk3_vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan100 prefixlen 64 scopeid 0x28
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (none)
status: no carrier
vlan: 100 vlanpcp: 0 parent interface: sk3
sk3_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan10 prefixlen 64 scopeid 0x14
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (none)
status: no carrier
vlan: 10 vlanpcp: 0 parent interface: sk3
sk3_vlan5: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,IPFW_FILTER> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan5 prefixlen 64 scopeid 0x27
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (none)
status: no carrier
vlan: 5 vlanpcp: 0 parent interface: sk3
pptpd0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
inet6 fe80::290:7fff:fe3f:cd95%pptpd0 prefixlen 64 scopeid 0x16
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
pptpd1: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd2: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd3: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd4: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd5: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd6: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd7: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd8: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd9: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd10: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd11: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd12: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd13: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd14: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd15: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
[2.1-BETA0][root@prop-router-rugby.local]/root(2):
Updated by Phil Lavin over 11 years ago
Note the above is with a subnet of /25. Seems most people have pissed off home - I'll run the update now and let you know in an hour or so.
Let me know if there's any more debug you want post-update.
Phil
Updated by Jim Pingle over 11 years ago
ok, check the ifconfig output again after the upgrade.
Somehow the IPs are ending up on the interface in the wrong order. Normally the actual interface IP is at the top of the list, and the aliases are below. Even if you could end up this way through some combination of adding/deleting/changing IPs and aliases, a normal reboot should have cleared it up.
Updated by Phil Lavin over 11 years ago
All is well with a /26 subnet now. Definitely rebooted it a bunch of times since reporting this bug both for upgrades to the latest snapshot and regular power cycles etc.
Issue started on upgrade from stable to 2.1-BETA0 so I guess the issue has been fixed - deliberately or otherwise :)
Thanks
[2.1-BETA1][root@prop-router-rugby.local]/root(1): ifconfig -a
msk0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:95
media: Ethernet autoselect
msk1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:94
media: Ethernet autoselect
msk2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:93
media: Ethernet autoselect
msk3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=c011b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE>
ether 00:90:7f:3f:cd:92
media: Ethernet autoselect
sk0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80008<VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:91
inet6 fe80::290:7fff:fe3f:cd91%sk0 prefixlen 64 scopeid 0xa
inet 31.24.0.195 netmask 0xffffffc0 broadcast 31.24.0.255
inet6 2a02:b90:7004::1 prefixlen 50
inet 31.24.0.198 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.196 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.200 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.201 netmask 0xffffffc0 broadcast 31.24.0.255
inet 31.24.0.202 netmask 0xffffffff broadcast 31.24.0.202
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd90%sk1 prefixlen 64 scopeid 0xb
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:8f
inet6 fe80::290:7fff:fe3f:cd8f%sk2 prefixlen 64 scopeid 0xc
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
sk3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd8e%sk3 prefixlen 64 scopeid 0xd
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
pflog0: flags=100<PROMISC> metric 0 mtu 33200
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x11
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
sk1_vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd95%sk1_vlan1 prefixlen 64 scopeid 0x12
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2a02:b90:7004:4000:: prefixlen 50
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 1 vlanpcp: 0 parent interface: sk1
sk1_vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:90
inet6 fe80::290:7fff:fe3f:cd95%sk1_vlan4 prefixlen 64 scopeid 0x13
inet 10.20.0.1 netmask 0xffffff00 broadcast 10.20.0.255
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 4 vlanpcp: 0 parent interface: sk1
sk3_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan10 prefixlen 64 scopeid 0x14
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (none)
status: no carrier
vlan: 10 vlanpcp: 0 parent interface: sk3
sk3_vlan5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan5 prefixlen 64 scopeid 0x15
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (none)
status: no carrier
vlan: 5 vlanpcp: 0 parent interface: sk3
sk3_vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:90:7f:3f:cd:8e
inet6 fe80::290:7fff:fe3f:cd95%sk3_vlan100 prefixlen 64 scopeid 0x16
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (none)
status: no carrier
vlan: 100 vlanpcp: 0 parent interface: sk3
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:81:2a:c6:f7:00
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: sk2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 12 priority 128 path cost 55
member: sk0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 55
pptpd0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd1: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd2: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
pptpd3: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd4: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd5: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd6: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd7: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd8: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd9: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd10: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd11: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd12: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd13: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd14: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
pptpd15: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
[2.1-BETA1][root@prop-router-rugby.local]/root(2):
Updated by Renato Botelho over 11 years ago
- Status changed from Feedback to Closed
Submitter reported problem is not happening on recent snapshots. Closing it.
Updated by Renato Botelho about 11 years ago
- Status changed from Closed to New
Reopen it since I could reproduce locally
Updated by Renato Botelho about 11 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Alias address are being set before main address when IPv6 is set to Track, it is fixed now.
Updated by Christoph Filnkößl about 11 years ago
Jim guided me here - I have got a similar problem on the recent 2.1-snapshot (March 7th).
Details are already described here: #2647
Short abstract:
We have to use DHCP for our static public IP. Additional virtual IPs are static.
When dhclient runs, IPs get mixed up and pfSense discovers a virtual IP as its WAN IP.
(normal public IP is at the end when using ifconfig, possible error in dhclient?)
Updated by Renato Botelho about 11 years ago
- Status changed from Resolved to New
- % Done changed from 100 to 50
Updated by Christoph Filnkößl almost 11 years ago
Is this bug currently being worked on?
Is there any way to help fixing the bug?
Updated by Ermal Luçi almost 11 years ago
- Status changed from New to Feedback
- % Done changed from 50 to 100
Applied in changeset b877d6351c614f58b68a3ab2c7b04ea7ea282961.
Updated by Ermal Luçi almost 11 years ago
Applied in changeset 4454f1f34841b07c2f8e5aa95b3e0d9a9e0ed9a2.
Updated by Christoph Filnkößl almost 11 years ago
That bug is NOT fixed yet.
It still exists on 2.1-RC0 from "Sun Jul 7 20:34:30"
Please tell me if I can support you.
Updated by Renato Botelho almost 11 years ago
- Status changed from Feedback to New
Updated by Renato Botelho almost 11 years ago
- Status changed from New to Feedback
Please check tomorrow's snapshot
Updated by Christoph Filnkößl almost 11 years ago
it's kind of working now.
following happens:- ifconfig - real (DHCP assigned) IP is on top of the virtual IPs
- pkill dhclient
- dhclient em4
- ifconfig - real IP is 0.0.0.0 and moves to the bottom (dhclient still running)
- ifconfig - real IP is 213.0.0.9 and moves to the top (dhclient finished)
I can't fully grasp your changes and how it's supposed to be working but I think you reached a working state!
Updated by Ermal Luçi almost 11 years ago
Yeah it fixed your issue but probably brought other issues.
I am still investigating how to better solve the other problems brought by this.
Updated by Jos van de Ven almost 11 years ago
I am having problems with Snort starting up twice on boot while a new WAN IP is detected when there isn't really a new WAN IP and the packages are restarted.
See also this discussion from me: [[http://forum.pfsense.org/index.php/topic,63568.90.html]]
Snort is restarted caused by check for new WAN IP. Snort has not completely started and pid file is not yet written. A second snort process is started because of pid file check and missing. Snort always takes a while to start on slower processors.
Updated by Thomas Rieschl almost 11 years ago
The error still seems to be there.
I erroneously created a new ticket for that bug (#3107). The problem didn't occur on the WAN interface, though, but on a bridge interface used on the LAN.
Interestingly, the problem doesn't occur on the "LAN" interface, i.e. when assigning a real network adapter. I'll try if OPTx interfaces are affected.
Updated by Thomas Rieschl almost 11 years ago
Thomas Rieschl wrote:
I'll try if OPTx interfaces are affected.
The problem doesn't occur on OPTx interfaces. when a real network interface is assigned to it. It also works when assigning a tagged VLAN to it.
But the problem also occurs, when using IPv6 instead of IPv4 on the bridged interface.
Updated by Ermal Luçi over 10 years ago
- Status changed from New to Feedback
Applied in changeset pfsense-tools:commit:29a8a72c23d5844787647cb478f2e672606aa2db.
Updated by Ermal Luçi over 10 years ago
Can you please try with tomorrows snapshots.
This should be properly fixed now.
Updated by Thomas Rieschl over 10 years ago
I just tested it but it doesn't seem to work :(
what I did:- fresh install in a KVM virtual machine on Debian 7 with 4 NICs with each on another bridge interface on the host, the first in the real home LAN bridge for internet and webgui connectivity, with the current live CD (pfSense-LiveCD-2.1-RC1-amd64-20130801-1938.iso)
- set up the WAN (vtnet0) interface on the command line and then two interfaces (IF1->vtnet1, IF2->vtnet2) in the webgui, with no IP address.
- bridged the two interfaces (IF1, IF2), created a new interface using the bridge (BR0) and gave that interface an IP address (192.168.16.1)
- created an IP alias on the BR0 interface (192.168.17.1)
- set up the following Firewall rule on the BR0 interface: pass Proto IPv4*, Source BR0 net, Port *, Dest *, Port *, GW *
- added the ip address 192.168.16.2/24 on the bridge interface on the host, which is bridged with the vtnet1, and pinged 192.168.16.1 from there. --> success
- rebooted pfsense. after the reboot, I could already see the wrong IP address on the console (192.168.17.1)
- tried to ping 192.168.16.1 from the VM host again --> fail
- added the IP address 192.168.17.2 on the same bridge interface on the host
- pinged 192.168.17.1 from the host --> success
so it seems, that your fix didn't work :(
if you want I can try and change the network setup to use the IP alias on the WAN interface and see if that works
Updated by Ermal Luçi over 10 years ago
Your description is a bit not usual here.
You are mixing subnets on different interfaces and its not clear what is what from the interfaces.
If you give an config.xml that shows the symptoms fine otherwise i think your is probably wrong configuration rather than anything else.
The wrong configuration is probably because the bridge is sharing the mac address with the interface it has as member and they cannot have the same range of ips on the same mac probably or somesuch.
Updated by Thomas Rieschl over 10 years ago
Sorry, if I described it too complicated.
I didn't do anything unusual. The configuration for the VM just represents a Firewall with four NIC interfaces. The first one acts as WAN, which has a private IP address beacause it's in my "real" LAN, behind the real firewall.
The others are just for making the bridge and test the different scenarios. It's actually quite similar to what I use on my production pfsense.
nic0 gets its IP address from the real firewall.
nic1 and nic2 are interfaces with no IP address. they are just used for being bridged. The error just occurs on a bridge interface.
then br0 is a brigde with nic1 and nic2 interfaces.
the br0 interface gets an IP address in the interface configuration and one additional in IP aliases. It's of course on an other subnet. That's why I need the IP alias. Why would I set an IP alias within the same subnet?
I use that type of configuration because I often have PCs and equipment, which need static IP addresses, which are definend by my customer. So, the easiest way to set up those components in my network is to give my firewall/router the same IP address which will be the router's IP from my client. That way I don't have to set up a separate network (no other router, no VLANs) and I can communicate withour problems with my current equipment (NAS, RDP from my work computer to the client's PCs, and so on).
I hope it's clearer now...
I'll attach a config file as soon I have one available.
Updated by Thomas Rieschl over 10 years ago
- File config-pfsense.localdomain-20130806121907.xml config-pfsense.localdomain-20130806121907.xml added
- File console_after.png console_after.png added
- File console_before.png console_before.png added
- File ifconfig_after.png ifconfig_after.png added
- File ifconfig_after-add-before-reboot.png ifconfig_after-add-before-reboot.png added
- File ifconfig_after-refresh.png ifconfig_after-refresh.png added
- File ifconfig_before.png ifconfig_before.png added
- File interfaces_after.png interfaces_after.png added
- File interfaces_before.png interfaces_before.png added
okey, here is the config file.
also, I've made screenshots.
console_before, ifconfig_before and interfaces_before are from before adding the IP alias.
ifconfig_after-add-before-reboot is just after adding the alias.
console_after, ifconfig_after and interfaces_after are made after adding the alias and rebooting. It's no problem if I don't reboot.
ifconfig_after-refresh is the screenshot, after the reboot, when I open the interface configuration of br0 and just click save and then apply. console and interfaces then just look like the "_before" screenshots.
It's interesting to notice that the order of the ip addresses in ifconfig are swapped.
I hope that helps.
Updated by Chris Buechler over 10 years ago
- Target version changed from 2.1 to 2.2
- Affected Version changed from 2.1 to All
Updated by Ermal Luçi over 10 years ago
This has been patched even on 2.1 but maybe final conclusion should be done if this ticket is closed.
Updated by Thomas Rieschl about 10 years ago
I just tried it again with the current 2.1.1 Snapshot (2.1.1-PRERELEASE (amd64) built on Mon Feb 24 16:48:44 EST 2014), but it still doesn't work.
After a restart the bridge interface gets the Alias IP instead of the one configured in Interfaces.
I tried it with upgrading from 2.1 and restoring the config file from above and a fresh install of the liveCD amd64, and manually setting the scenario described above.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Closed
root issue is #3997, closing this in favor of that.