0

Our network currently consists of 3 subnets on the same link:

  • 1.2.3.0/24 is the global subnet
  • 10.1.0.0/16 is used for NAT (because there are far more than 200 clients)
  • 192.168.0.0/16 is the "guest network" with a simple captive portal for unknown hosts

Our dhcpd host has the following /etc/network/interfaces:

auto lo
iface lo inet loopback

auto eth0
allow-hotplub eth0
iface eth0 inet static
    address 1.2.3.2
    netmask 255.255.255.0
    gateway 1.2.3.1

iface eth0:1 inet static
    address 192.168.0.1
    netmask 255.255.0.0

iface eth0:2 inet static
    address 10.1.0.2
    netmask 255.255.0.0

and this dhcpd.conf:

authoritative;
# option definitions common to all supported networks...
option domain-name "example.com";
option domain-search "example.com";
option domain-name-servers 8.8.8.8;
option ntp-servers 1.2.3.8;

default-lease-time 600;
max-lease-time 600;


shared-network "corp" {
  include "/etc/nat-classes.conf";

  subnet 1.2.3.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
    option broadcast-address 1.2.3.255;
    option routers 1.2.3.1;
    default-lease-time 600; 
    max-lease-time 600; 
    deny unknown-clients;
  }

  subnet 10.1.0.0 netmask 255.255.0.0 {
    option subnet-mask 255.255.0.0;
    option broadcast-address 10.1.255.255;
    option routers 10.1.0.1;
    default-lease-time 600;
    max-lease-time 600;

    include "/etc/nat-pools.conf"; # every user owns a pool of addresses
  }

  subnet 192.168.0.0 netmask 255.255.0.0 {
    pool {
      range 192.168.0.3 192.168.255.254;
      deny known-clients;
    }
    option subnet-mask 255.255.0.0;
    option broadcast-address 192.168.255.255;
    option routers 192.168.0.1;
    option domain-name-servers 192.168.0.1;
    filename "pxelinux.0";
    next-server 192.168.0.1;
    allow unknown-clients;
  }
}
# ... known host definitions ...

We now observed the following:

  • The DHCP OFFERs for the 10.1/16 and 192.168/16 subnets contain the DHCP option 54 (DHCP Server Identifier) with the server's public IP address (1.2.3.2), furthermore, the IP header has a Source Address of 1.2.3.2 and a Destination Address in the target subnet.
  • Shortly before the end of lease time clients in these subnets try to reach 1.2.3.2 for a lease renew and fail (or they don't even try because it's not an address in their configured subnet?)
  • At least on Android and Win 10 this leads to a short, but significant Layer 3 disconnection.

We know there is a server-identifier option according to dhcpd.conf(5):

The usual case where the server-identifier statement needs to be sent is
when a physical interface has more than one IP  address,  and
the  one  being  sent  by  default isn't appropriate for some or
all clients served by that interface.  Another common case is when an
alias is defined for the purpose of having a consistent IP
address for the DHCP server, and it is desired that the clients use this IP
address when contacting the server.

But when setting this option in all 3 respective subnet definitions, DHCP stops working on the 10.1/16 and 192.168/16 subnets because for some reason the DHCP OFFERs (now with correct Src IP and DHCP Server Identifier headers) won't reach the clients anymore.

Despite the fact that a lease time of 600 in combination with our captive portal is everything but a secure solution, how can we make DHCP on the different subnets work properly with clients issuing renews the correct way as soon as the lease time runs out?

cbix
  • 141
  • 5

1 Answers1

0

I finally solved the problem myself. We had DHCP snooping enabled on the switches so I entered the 10.1.0.2 IP as an authorized IP on the switches and put the server-identifiers back in the config and voilá, it worked!

shared-network "corp" {
  subnet 1.2.3.0 netmask 255.255.255.0 {
    server-identifier 1.2.3.2;
    # ...
  }
  subnet 10.1.0.0 netmask 255.255.0.0 {
    server-identifier 10.1.0.2;
    # ...
  }
  subnet 192.168.0.0 netmask 255.255.0.0 {
    server-identifier 192.168.0.1;
    # ...
  }
}
cbix
  • 141
  • 5