DHCP: Device on green gets blue IP [SOLVED]

Network DHCP
1

I am occasionally observing something odd: Laptop on GREEN receives an IP in the BLUE IP range.

Setup:

IPfire with RED, GREEN, BLUE, ORANGE, all with their own physical LAN port.

RED is public IP, GREEN is my LAN (10.0.0.x/24), BLUE is wired towards an WRT WIFI router (10.1.1.x/24), and ORANGE is my DMZ (with static IPs).

GREEN and BLUE have each a DHCP server with corresponding IP ranges to be served on each subnet.

Usually everything works as expected, but I have a Laptop which is just occasionally use. I have a LAN cable on my desk plugged into a switch on the GREEN interface to connect this Laptop (WIFI is disabled). Normally it get an IP in the GREEN range as it should. It also has a fixed lease registered via its MAC.

However, every once in a while, the laptop gets an IP in the BLUE range, and obviously then it won’t work (i.e. no internet, as the BLUE IP does not get routed correctly from/in the GREEN).

So far I either reboot the laptop, or I disconnect the cable from the switch and plug it back in. But this does not always fix it, and it’s quite annoying. So I am always wondering why/how is a BLUE IP served on my wired GREEN subnet.

Any ideas? Normally the DHCP broadcast to get an IP should only be seen within each subnet, right?

2

Are there any connections between the green interface, the blue interface, the switch, your laptop?

The DHCP server decides based on the incoming interface which address pool is used.

3

Hi, thanks for you reply.

Of course not. The subnets are strictly separated.

(but tbh, I was also already wondering whether there might be some device with WLAN and LAN doing some invisible bridging. But this should not be the case.)

Green has it’s own switch. Blue just has one cable going to the WRT.

The DHCP server decides based on the incoming interface which address pool is used.

This is what I would expect as well, however, I do see occasionally an IP from the BLUE range being served to a device connected to the switch in the GREEN subnet.

4

The pool decision is based on the IP nets of the interfaces

subnet 192.168.10.0 netmask 255.255.255.0 #GREEN
{
pool {
	range 192.168.10.128 192.168.10.159;
     }
	option subnet-mask 255.255.255.0;
	option domain-name "bitsch.localdomain";
	option routers 192.168.10.254;
	option domain-name-servers 192.168.10.254;
	option ntp-servers 192.168.10.254;
	default-lease-time 3600;
	max-lease-time 7200;
	option wpad "http://192.168.10.254:81/wpad.dat";
	option wpad "http://192.168.10.254:81/proxy.pac";
} #GREEN

for example.

But fixed leases are hardcoded to the MAC address

host fix4 # XBOXONE
{
	hardware ethernet 1c:1a:df:xx:yy:zz;
	fixed-address 192.168.10.14;
}

If your laptop ( OS? ) sometimes signals a MAC registered to a blue IP, it gets that IP.

BTW: Your address pools ( static, dynamic, fixed ) are disjunct also, I suppose. dhcpd doesn’t function reliable with a mix. If I remember right the processing is

  • check if a fixed host definition exists for the MAC
  • choose an IP from a pool based on the incoming network; checks for availabilty are done by ICMP

A device can become a ‘static host’ if it has a configuration for alternative IP values ( use IP/mask/gateway/DNS/… )

5

The process of IP assigment can be watched on the IPFire side

  • either by tail -f /var/log/messages | grep dhcpd from a shell
  • or by studying the WUI page Logs → System Logs, Section DHCP Server

The messages contain the the associated MAC address.

Self assignment by the device to a wrong network should show up as ‘IPv4: martian source’ in the kernel logs. A ‘ll header’ message may be accompanying.

6

Thanks for your help buddy.

My config for the 2 subnets (from dhcpd.conf) :

subnet 10.1.1.0 netmask 255.255.255.0 #GREEN
{
pool {
	range 10.1.1.100 10.1.1.149;
     }
	option subnet-mask 255.255.255.0;
	option domain-name "MyLAN";
	option routers 10.1.1.250;
	option domain-name-servers 10.1.1.250, 1.1.1.2;
	option ntp-servers 10.1.1.250;
	default-lease-time 3600;
	max-lease-time 7200;
} #GREEN

subnet 10.0.0.0 netmask 255.255.255.0 #BLUE
{
pool {
	range 10.0.0.100 10.0.0.200;
     }
	option subnet-mask 255.255.255.0;
	option domain-name "MyWLAN";
	option routers 10.0.0.250;
	option domain-name-servers 10.0.0.250, 1.1.1.2;
	option ntp-servers 10.0.0.250;
	default-lease-time 3600;
	max-lease-time 7200;
} #BLUE

And the static mapping for the Laptop (in GREEN), bottom of same config file:

host fix0 # MacBook
{
	hardware ethernet 0c:4d:e9:xx:xx:xx;
	fixed-address 10.1.1.115;
}

And, following your hint using:

tail -f /var/log/messages | grep dhcpd

I get this:

[root@ipfire ~]# tail -f /var/log/messages | grep dhcpd
Jun 21 12:27:22 ipfire dhcpd: DHCPDISCOVER from 0c:4d:e9:xx:xx:xx (MacBook) via blue0
Jun 21 12:27:22 ipfire dhcpd: uid lease 10.1.1.115 for client 0c:4d:e9:xx:xx:xx is duplicate on 10.1.1.0/24
Jun 21 12:27:22 ipfire dhcpd: DHCPDISCOVER from 0c:4d:e9:xx:xx:xx via green0
Jun 21 12:27:22 ipfire dhcpd: DHCPOFFER on 10.1.1.115 to 0c:4d:e9:xx:xx:xx via green0
Jun 21 12:27:23 ipfire dhcpd: DHCPOFFER on 10.0.0.108 to 0c:4d:e9:xx:xx:xx (MacBook) via blue0
Jun 21 12:27:23 ipfire dhcpd: Dynamic and static leases present for 10.1.1.115.
Jun 21 12:27:23 ipfire dhcpd: Remove host declaration fix0 or remove 10.1.1.115
Jun 21 12:27:23 ipfire dhcpd: from the dynamic address pool for 10.1.1.0/24
Jun 21 12:27:23 ipfire dhcpd: uid lease 10.1.1.115 for client 0c:4d:e9:xx:xx:xx is duplicate on 10.1.1.0/24
Jun 21 12:27:23 ipfire dhcpd: DHCPREQUEST for 10.1.1.115 (10.1.1.250) from 0c:4d:e9:xx:xx:xx via blue0: wrong network.
Jun 21 12:27:23 ipfire dhcpd: DHCPNAK on 10.1.1.115 to 0c:4d:e9:xx:xx:xx via blue0
Jun 21 12:27:23 ipfire dhcpd: Dynamic and static leases present for 10.1.1.115.
Jun 21 12:27:23 ipfire dhcpd: Remove host declaration fix0 or remove 10.1.1.115
Jun 21 12:27:23 ipfire dhcpd: from the dynamic address pool for 10.1.1.0/24
Jun 21 12:27:23 ipfire dhcpd: uid lease 10.1.1.115 for client 0c:4d:e9:xx:xx:xx is duplicate on 10.1.1.0/24
Jun 21 12:27:23 ipfire dhcpd: execute_statement argv[0] = /usr/sbin/unbound-dhcp-leases-client
Jun 21 12:27:23 ipfire dhcpd: execute_statement argv[1] = commit
Jun 21 12:27:23 ipfire dhcpd: execute_statement argv[2] = ADDRESS=10.1.1.115
Jun 21 12:27:23 ipfire dhcpd: execute_statement argv[3] = NAME=MacBook
Jun 21 12:27:23 ipfire dhcpd: DHCPREQUEST for 10.1.1.115 (10.1.1.250) from 0c:4d:e9:xx:xx:xx via green0
Jun 21 12:27:23 ipfire dhcpd: DHCPACK on 10.1.1.115 to 0c:4d:e9:xx:xx:xx via green0

So, if I see this right, then the first discover packet seems to come in on the BLUE.

Then a moment later there is another discover packet received in GREEN.

However, there a offer packets apparently sent on GREEN and BLUE, which might just result in a race condition. Whatever offer is reaching the client first. Do I interpret this right?

And then it seems to sort out the mess. (Request with the fix on the wrong net, and the at the bottom the correct request and ack packages.

Any idea on how to sort that out?

7

Two things:

  • first you should examine your physical connection MacBook <—> IPFire. Seems your laptop is connected on both interfaces. I suppose the xx:xx:xx parts of the MAC are identical
  • your fixed lease IP for the laptop is element of the dynamic pool. This may give problems.
8

Thanks again.

This is really weird. As there is only one cable from the BLUE port on the FW going to the WRT.

I have changed the fixed lease to an IP outside the DHCP range. I’ll keep an eye on it.

EDIT: On boy! I’d rather not admit the following…

There was in deed a cable behind the shelf in the other room (storage room where the WRT lives), and for what ever reason, the cable was plugged into the back of the WRT (it has a build-in switch), don’t ask me why, but the other end landed in a small switch behind that shelf. And guess what, that hidden switch lead to the GREEN subnet. How silly.

Ok, thanks for pushing me in the right direction. And now I go sinking into the ground with shame.