Multiple DHCP scopes

mastrboy

will we se multiple DHCP scopes support in pfsense in the future? or is it already possible, but i'm just to blind to see it? ???

hoba

What do you mean by this? Different DHCP per interface? If this is what you mean you are too blind to see ;) At services>dhcp server you will have a tab for each internal interface to configure individual settings.

mastrboy

nope, not what i mean ;)

It's a little hard to explain (i'll create a screenshot later)

mastrboy

so here is a illustrated attempt to explain, first an example from microsoft dhcp server:

second is my own illustration:

sullrich

It's not possible currently and it is not on any of the devs lists that I know of.

mastrboy

ok, too bad though, hope some of the devs see this post and thinks it's a good idea ;)

sullrich

I doubt many of them will get excited about this. I know that I really don't need these features but you never know…

MrMoo

Trust networking people to invent new terms for ones we already have, it appears "DHCP scoping" is just VLAN support in DHCPD. Currently one DHCPD is run per physical network, this means for VLAN support you need to use the shared network stanza:


  shared-network "DHCP Vlan 4" {
          subnet 10.4.0.0 netmask 255.255.0.0 {
                  option routers 10.4.10.253;
                  authoritative;

                  # Begin authorized client pool
                  pool {
                          option domain-name-servers 10.2.14.4,10.2.14.2;
                          one-lease-per-client true;
                          max-lease-time 120;
                          default-lease-time 120;
                          range 10.4.1.1 10.4.1.49;
                          deny unknown clients;
                  } # End authorized client pool
          } # End subnet 10.4.0.0/16
  } # End shared network DHCP Vlan 4

  # Test Vlan 5 begin
  shared-network "Test Vlan 5" {
          subnet 10.5.0.0 netmask 255.255.0.0 {
                  option routers 10.5.10.253;
                  authoritative;

                  # Begin unauthorized pool
                  pool {
                          option domain-name-servers 10.4.10.10;
                          one-lease-per-client true;
                          max-lease-time 120;
                          default-lease-time 120;
                          range 10.5.200.1 10.5.200.49;
                          allow unknown clients;
                  } # End unauthorized pool

                  # Begin authorized pool
                  pool {
                          option domain-name-servers 10.2.14.4,10.2.14.2;
                          one-lease-per-client true;
                          max-lease-time 691200;
                          default-lease-time 691200;
                          range 10.5.1.1 10.5.1.49;
                          deny unknown clients;
                  } # End authorized pool
          } # End subnet 10.5.0.0/16
  } # End shared-network Test Vlan 5

I guess slightly similar is the support of multiple ranges per interface. The answer depends on how VLANs are currently working, are they presented through everywhere as multiple interfaces. If DHCPD has problems using each VLAN device then extra logic would be required to automagically group the VLANs on a physical interface and use the shared configuration.

MrMoo

I'll have a look at implementing this as I have a layer 4 switch, but don't hold your breath … ;D

MrMoo

Oh nice, only VMWare ESX has VLAN tagging support in the client, this is inconvenient.

:-\

ptaylor

Actually, we are looking for multiple scope support now. It doesn't really have to involve VLANs… Basically, there is a gateway address field in the DHCP request, if it has passed through a Cisco router (using the "ip helper" command to turn the DHCP Discover broadcast into a unicast directed at a specific IP Address), the DHCP server sees that gateway address and that is how it determines which scope the requesting device should be part of...

An example might help here..

We have a Headquarters in City A and remote sites in Cities B and C. Each site has a class C address.

Site A's network address is 192.168.1.0.
Site B's network address is 192.168.2.0.
Site C's network address is 192.168.3.0.

The router at each site is x.x.x.1 with an "ip helper" assigned, pointing DHCP requests to 192.168.1.100 (a server at Site A).

Workstation B (at Site B) broadcasts a DHCP Discover frame. The router at site B receives that frame and turns it into a unicast packet destined for 192.168.1.100, putting his own IP Address (192.168.2.1) in the gateway address field inside the packet.

The 192.168.1.100 server receives the unicast DHCP Discover frame, sees that it passed through the 192.168.2.1 gateway and uses that address to determine the address range to assign to that client. Similarly, workstations at Site C will have their DHCP packets forwarded by their router, so the DHCP server can easily differentiate between remote sites... Not that they have to be remote.

In our case, we have a new Cisco 6509 core switch, which is effectively a very large router, and we are subnetting everything on a per wiring closet basis. Having one central DHCP server to handle all the remote closet switches (about 20) is something I'm working on right now. So far, it looks like I'll end up using Ubuntu LTS Server with dhcpd to handle it, as nothing else gives us quite the flexibility we need.

MrMoo

I just commited VLAN DHCP support to my own branch, doesn't touch the GUI at all.

Here's the config it can generate:


option domain-name "local";
default-lease-time 7200;
max-lease-time 86400;
authoritative;
log-facility local7;
ddns-update-style none;

shared-network "vlan 69 on vr0" {
        subnet 10.69.0.0 netmask 255.255.255.0 {
                pool {
                        range 10.69.0.10 10.69.0.20;
                }
                option routers 10.69.0.1;
                next-server 10.69.0.1;
                filename "pxelinux.0";
        }
}

shared-network "vlan 68 on vr0" {
        subnet 10.68.0.0 netmask 255.255.255.0 {
                pool {
                        range 10.68.0.10 10.68.0.20;
                }
                option routers 10.68.0.1;
                next-server 10.68.0.1;
                filename "pxelinux.0";
        }

        subnet 10.0.0.0 netmask 255.255.255.0 {
        }

}

If you are lucky the attached patch works, but the pf team have modified the dhcp function a bit from m0n0 and I make some rather grand assumptions in the code.

services.inc.vlan-dhcp.patch.txt