Two lan interfaces DHCP assigning same subnet to both

darksilver · Nov 22, 2010, 12:58 AM

I set up two LAN interfaces, then went to the DHCP settings and enabled the DHCP for both interfaces

lan interface:
Subnet 192.168.1.0
Subnet mask 255.255.255.0
Available range 192.168.1.0 - 192.168.1.255
range: 192.168.1.10 - 192.168.1.150

OPT1 interfacae:
Subnet 192.168.2.0
Subnet mask 255.255.255.0
Available range 192.168.2.0 - 192.168.2.255
range: 192.168.2.10 - 192.168.2.150

seemed to be working ok at first, but then i connected new computers to the network (LAN interface) they were assigned ip's 192.168.2.XXX …. makes no sense to me, OPT1 interface isn't even connected to a switch at all, it uses a crossover cable to connect directly to another computer.

can anyone say why its assigning 192.168.2.xxx on the LAN interface?

kyle

Hi,

I have the same exact problem Kyle does. I have two LAN Interfaces
dc0 interface:
Subnet 192.168.2.0
Subnet mask 255.255.255.0
Available range 192.168.2.0 - 192.168.2.255
range: 192.168.2.6 - 192.168.2.149

dc1 interface:
Subnet 192.168.3.0
Subnet mask 255.255.255.0
Available range 192.168.3.0 - 192.168.3.255
range: 192.168.3.1 - 192.168.3.199

When a new client connects to the LAN interface it gets an ip 192.168.3.199 instead of the 192.168.2.79. From the syslog logs i can see the following:

DHCPDISCOVER from 08:00:27:c1:ad:22 via dc1
DHCPDISCOVER from 08:00:27:c1:ad:22 via dc0
DHCPOFFER on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
DHCPOFFER on 192.168.2.79 {organization.network.net} to 08:00:27:c1:ad:22 (organization) via dc0
DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc1
DHCPACK on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc0: wrong network.
DHCPNAK on 192.168.3.199 to 08:00:27:c1:ad:22 via dc0

It seems that the broadcast packets (DHCPDISCOVER and DHCPOFFER) always reach both subnets even though they are physically two separate Ethernet ports, and the client PC always gets the higher ip address offered :(
Does any one know a way to make this to work ? (I've tried adding firewall rules to block the traffic from one subnet to the other with no success)

wallabybob · Nov 22, 2010, 12:20 AM

darksilver:
dc0 and dc1 are connected to the same switch? This is a broken configuration for this sort of reason.

If you really want to isolate dc0 and dc1 put them on separate switches (or separate VLANs if your switch is VLAN capable).

If you don't want to isolate dc0 and dc1 (having them on the same switch doesn't give any effective isolation) then drop the pretence and use just one interface.

kage: Do you have the same misconfiguration as darksilver?

darksilver · Nov 22, 2010, 1:06 AM

@wallabybob:
dc0 and dc1 are two ethernet ports on my pfsense and they DO NOT have any kind of physical connectivity between them.

wallabybob · Nov 22, 2010, 4:45 AM

@darksilver:

@wallabybob:
dc0 and dc1 are two ethernet ports on my pfsense and they DO NOT have any kind of physical connectivity between them.

Virtual connectivity? A software bridge? A hardware bridge?

Its pretty unusual that two DHCP requests from the same MAC address should appear on two unconnected networks at around the same time.

Its possible there is a weird bug in dhcpd. What pfSense version are you running?

Your DHCP log shows:

DHCPDISCOVER from 08:00:27:c1:ad:22 via dc1
DHCPDISCOVER from 08:00:27:c1:ad:22 via dc0
DHCPOFFER on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
DHCPOFFER on 192.168.2.79 {organization.network.net} to 08:00:27:c1:ad:22 (organization) via dc0
DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc1
DHCPACK on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc0: wrong network.
DHCPNAK on 192.168.3.199 to 08:00:27:c1:ad:22 via dc0

Note 192.168.3.199 was reportedly offered to a system on dc1 and then a system on dc0 requests that same IP address. How did the system on dc0 get to see the offer supposedly sent on dc1? (I also wondered if you might have two systems with the same MAC address, one visible by dc0 and the other visible by dc1, but that wouldn't explain what's in the log.)

Did you ever have dc0 and dc1 bridged in pfSense? Maybe it wasn't correctly cleaned out. (I've seen a couple of instances of pfSense 2.0 BETA seemingly remembering parts of a previous configuration of an interface.) Please post the output of the shell command # ifconfig -a

I guess you could also run some tcpdumps to see if the DHCP requests from the same MAC address really do come in over both dc0 and dc1.

jimp · Nov 22, 2010, 4:54 AM

Yes, according to those log entries, something is bridging or combining those broadcast domains.

It could be a software bridge, a cable between the involved switches, a dual homed host misbehaving, etc, but it's not pfSense deciding to hand out the "wrong" subnet on the "wrong" interface on its own.

You definitely should not be seeing traffic from the same MAC on both interfaces if they are truly separate.

darksilver · Nov 22, 2010, 9:56 PM

Hi again,

First of all thank you all for your replies!

I've connected the dc1 port to a switch with nothing else connected to it. The client PC still gets the wrong ip address (it is a Windows machine). If I disconnect the dc1 port(interface down) it works fine. Unless packets travel by air (like magic… :P) there is not any possible connectivity between both interfaces. But I'm pretty sure this is caused because pfsense for some reason is allowing it.
I took a wireshark trace of both situations ("normal" : with the dc1 DHCP server off, and "abnormal" : with DHCP server active on both interfaces), and I can see that the DCHPOFFER is coming from to different mac addresses (by the way, it is a 4 port Ethernet card, so that is why the mac are very similar). I believe this could only mean that pfsense is not working as expected or some other obscure configuration is needed...
I'm using pfsense version 1.2.3

Wireshark traces attached (please remove jpg extension).

Regards

wiresahark.rar.jpg

jimp · Nov 22, 2010, 10:06 PM

As requested previously, we need the output of "ifconfig -a" from a shell prompt or Diagnostics > Command

darksilver · Nov 22, 2010, 10:30 PM

Sorry forgot to take that… It is interesting to see that bridge0 has dc0 and dc1... but on the interface configuration of dc1 in pfsense I've set "bridge with" option to none.

$ ifconfig -a
dc0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=8 <vlan_mtu>ether 00:06:2b:01:50:ad
inet 192.168.2.250 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::206:2bff:fe01:50ad%dc0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
dc1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=8 <vlan_mtu>ether 00:06:2b:01:50:ae
inet6 fe80::206:2bff:fe01:50ae%dc1 prefixlen 64 scopeid 0x2
inet 192.168.3.250 netmask 0xffffff00 broadcast 192.168.3.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
dc2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=8 <vlan_mtu>ether 00:06:2b:01:50:af
media: Ethernet autoselect
status: no carrier
dc3: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=8 <vlan_mtu>ether 00:06:2b:01:50:b0
media: Ethernet autoselect
status: no carrier
xl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=9 <rxcsum,vlan_mtu>ether 00:0a:5e:20:3a:c5
inet6 fe80::20a:5eff:fe20:3ac5%xl0 prefixlen 64 scopeid 0x5
inet 192.168.1.64 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=41 <up,running>metric 0 mtu 1460
pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
pflog0: flags=100 <promisc>metric 0 mtu 33204
bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
ether ce:9f:dd:2a:b3:75
id 00:06:2b:01:50:ad priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:06:2b:01:50:ad priority 32768 ifcost 0 port 0
member: dc0 flags=1e7 <learning,discover,stp,edge,autoedge,ptp,autoptp>ifmaxaddr 0 port 1 priority 128 path cost 200000 proto rstp
role designated state forwarding
member: dc1 flags=1e7 <learning,discover,stp,edge,autoedge,ptp,autoptp>ifmaxaddr 0 port 2 priority 128 path cost 200000 proto rstp
role designated state forwarding</learning,discover,stp,edge,autoedge,ptp,autoptp></learning,discover,stp,edge,autoedge,ptp,autoptp></up,broadcast,running,simplex,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></rxcsum,vlan_mtu></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast>

jimp · Nov 22, 2010, 10:31 PM

That bridge is definitely your problem.

What about on dc0, does it also not have a bridge option set?

If that persists after a reboot, something in your config is doing it. That doesn't happen by default or automatically.

darksilver · Nov 23, 2010, 12:54 AM

Hi,

dc0 also has the "Bridge with" option set to none. However I tried force saving the same configuration again and then rebooted pfsense. And after that, the bridge was gone :)
I've enabled the DHCP on both interfaces and now everything works fine(I will do some more tests though!). I remember that some time ago when I first tried to configure the second interface dc1 I've tried to bridge it with some other interface. Even though I think pfsense has been rebooted a few times after that, it seems that for some reason that bridge interface never was removed and that was the reason for this strange behavior.
Thank you very much jimp and wallabybob for your support! This forum rules ;)