TESTING NEEDED: Multiple DHCP pools within a subnet
-
I just committed initial support for multiple DHCP pools inside of a subnet, and you can set options specific to that pool to have the pools act differently.
https://github.com/bsdperimeter/pfsense/commit/cba980f6a4fafa55b1eb11621e33942f149061ff
For example, you can have:
Pool A deny MAC prefix of AA:BB, using one set of addresses with one gateway
Pool B allow MAC prefix of AA:BB, using a different set of addresses and a different gateway, and DNS, etc.It would also allow you to have servers/static maps in the middle of a subnet by making the main range at the start of the subnet and a pool after the static addresses.
One thing it lacks yet is input validation to make sure that you are not entering overlapping subnets.
If you are already on the latest snapshot, apply the commit above using the system patches package, gitsync, or wait for the next new snapshot and give it a try.
It worked for me in a VM environment using the above scenario. I made two pools, watched the VM client pick up an IP from the first pool. Then I denied the VM's MAC access to the first pool, reconnected it, and it pulled an IP from the second pool, and so on. But of course people out in the real world can usually dream up more scenarios than I can possibly test myself. So have at it and reply here with what does or doesn't work.
There should effectively be no change for people running without pools. They're completely optional.
-
great, trying it out right now
-
If someone is crazy enough to want to try this on 2.0.1/2.0.2, here is a patch that can be applied using the system patches package:
http://files.chi.pfsense.org/jimp/patches/pools-202.patch
(Path strip = 0, base = /) -
Did some short tests.
I didn't see anything not working.A suggestion: Could you allow subnets availlable with a VIP as well?
(usage scenario: provide a seperate DHCP-range/subnet for all "unknown" clients) -
OK.
Those subnets can't be done the same way they require special coding and syntax for "shared network" in the DHCP config. The pools I did this way are much easier and more often requested.
We do have code for the shared network way but it hasn't found its way into the open source repo yet, not sure what the ETA on that might be.
I do still need to code up the input validation for this though.
-
Yeah i figured it might be not as easy as just allowing a different IP range ^^"
After playing a bit more.
Would it take much to create MAC-aliases?
In the field where you can define MAC's which are allowed within a range, such an alias would be perfect. -
No, there isn't a way to do that yet and it wouldn't make sense to do that until such time as pf can actually support filtering by MAC. It would require hacking it into the alias system in quite an ugly way since they couldn't be used by pf, and all the current aliases can.
The intent of the mac filtering option wasn't for lists of full MAC addresses anyhow, but primarily targeted at MAC prefixes, to give different brands/types of devices a different pool, such as a dedicated pool for phones, or similar.
-
pf can't filter by MAC, but ipfw can (incl. partial match).
Motivated by this thread http://forum.pfsense.org/index.php?topic=45596.0 several months ago I did some testing with filtering DHCP traffic by MAC using ipfw, however the dhcpd method is cleaner imho.
-
I can't get this patch to install. i enter the cba980f into the commit ID space, download the pacth, but when testing i receive
Patch can NOT be applied cleanly (detail)
Patch can NOT be reverted cleanly (detail)What am I doing wrong?
From the cleanly link
_Output of full patch apply test: /usr/bin/patch –directory=/ -t -p1 -i /var/patches/5088502b24be6.patch --check --forward
Hmm... Looks like a unified diff to me...
The text leading up to this was:|From cba980f6a4fafa55b1eb11621e33942f149061ff Mon Sep 17 00:00:00 2001
|From: jim-p
|Date: Sun, 16 Sep 2012 19:30:27 -0400
|Subject: [PATCH] Add support for multiple DHCP pools within the interface's
| subnet, and allow most of the settings for the main range
| to be set specific inside the pool. (e.g. it allows setting
| different gateways and DNS for different pools). Still
| needs improved input validation to prevent overlapping
| ranges/pools.
|
|–-
| etc/inc/services.inc | 160 ++++++++++++++-----
| etc/inc/xmlparse.inc | 2 +-
| etc/inc/xmlreader.inc | 2 +-
| usr/local/www/services_dhcp.php | 323 +++++++++++++++++++++++++++++----------
| 4 files changed, 364 insertions(+), 123 deletions(-)
|
|diff --git a/etc/inc/services.inc b/etc/inc/services.inc
|index 1834e37..e713ebf 100644
|--- a/etc/inc/services.inc+++ b/etc/inc/services.inc Patching file etc/inc/services.inc using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 510. Hunk #2 ignored at 541. Hunk #3 ignored at 563. Hunk #4 ignored at 674. Hunk #5 ignored at 728. 5 out of 5 hunks ignored--saving rejects to etc/inc/services.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/etc/inc/xmlparse.inc b/etc/inc/xmlparse.inc
|index ce7f4cd..d7ccc29 100644
|--- a/etc/inc/xmlparse.inc+++ b/etc/inc/xmlparse.inc Patching file etc/inc/xmlparse.inc using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 47. 1 out of 1 hunks ignored--saving rejects to etc/inc/xmlparse.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/etc/inc/xmlreader.inc b/etc/inc/xmlreader.inc
|index 96353d2..1678843 100644
|--- a/etc/inc/xmlreader.inc+++ b/etc/inc/xmlreader.inc Patching file etc/inc/xmlreader.inc using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 51. 1 out of 1 hunks ignored--saving rejects to etc/inc/xmlreader.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/usr/local/www/services_dhcp.php b/usr/local/www/services_dhcp.php
|index 078d099..47e8b49 100755
|--- a/usr/local/www/services_dhcp.php+++ b/usr/local/www/services_dhcp.php Patching file usr/local/www/services_dhcp.php using Plan A... Ignoring previously applied (or reversed) patch. Hunk #1 ignored at 94. Hunk #2 ignored at 124. Hunk #3 ignored at 249. Hunk #4 ignored at 363. Hunk #5 ignored at 388. Hunk #6 ignored at 501. Hunk #7 ignored at 559. Hunk #8 ignored at 685. Hunk #9 ignored at 694. Hunk #10 ignored at 732. Hunk #11 ignored at 768. Hunk #12 ignored at 879. Hunk #13 ignored at 887. Hunk #14 ignored at 908. Hunk #15 ignored at 935. Hunk #16 ignored at 1024. Hunk #17 ignored at 1097. 17 out of 17 hunks ignored--saving rejects to usr/local/www/services_dhcp.php.rej Hmm... Ignoring the trailing garbage. done Close_ -
What are you trying to apply it to? 2.0.1? 2.0.2? 2.1?
It's not needed on 2.1, the functionality is already there.
Given that it's ignoring everything that seems to be the case.
-
ipv6 not normal work in Multiple DHCP pools with V2.1
-
The feature was not added to the IPv6 DHCP settings. Only IPv4.
-
I set a different DNS server ( 208.67.222.222 ) on Pool-Specific Options. but that did not get to resolv.conf on the linux client. The client was even rebooted to test. resolv.conf instead gets the dns servers defined in main pool.
Also tried to set NTP time server to 0.debian.pool.ntp.org . the result was this message at top of the screen: "A valid IP address must be specified for the primary/secondary NTP servers."
-
Does using a hostname in the NTP server field work on the main tab? I thought we required an IP there.
DNS should work, it did last I knew. You can check /var/dhcpd/etc/dhcpd.conf that it's getting into the pool config. It is when I look on mine, though I don't have a client hooked up behind that test VM to do a proper check at the moment.
-
Does using a hostname in the NTP server field work on the main tab? I thought we required an IP there.
an IP is needed there. however i assumed that since an IP is not needed at General Setup then an IP would not be needed in dhcp server.
Just read isc-dhcp dhcp-options man page and now see that IP is needed.
DNS should work, it did last I knew. You can check /var/dhcpd/etc/dhcpd.conf that it's getting into the pool config. It is when I look on mine, though I don't have a client hooked up behind that test VM to do a proper check at the moment.
the pool config is OK at /var/dhcpd/etc/dhcpd.conf
pool { option domain-name-servers 127.0.0.1,172.50.24.2; range 172.50.24.100 172.50.24.200; } pool { option domain-name-servers 127.0.0.1,208.67.222.222; deny unknown-clients; default-lease-time 600; range 172.50.24.11 172.50.24.20; }here is more client info:
t520 /etc # cat resolv.conf # Generated by NetworkManager domain fantinibakery.com search fantinibakery.com nameserver 127.0.0.1 nameserver 172.50.24.2 t520 /etc # ip a .... 3: wlan0: <broadcast,multicast,up,lower_up>mtu 1500 qdisc mq state UP qlen 1000 link/ether 10:0b:a9:69:21:70 brd ff:ff:ff:ff:ff:ff inet 172.50.24.11/24 brd 172.50.24.255 scope global wlan0 inet6 fe80::120b:a9ff:fe69:2170/64 scope link valid_lft forever preferred_lft forever</broadcast,multicast,up,lower_up>Also I was not able to add the client fixed lease to the 'additional pool'. tried a few things and it always ended up at bottom of the main pool page.
-
Hmm that DNS config looks OK, not sure why it didn't go to the client properly.
Also static mappings are not pool specific, they are global for an interface. You can't define a static mapping inside a pool.
I made a commit earlier today to remove the static mapping list from the pool page since it's not relevant.To control who gets into a specific pool you need to use the allow/deny MAC boxes. At the moment they're just comma-separated lists. they could be changed into lists (like aliases) in the future if we get a proper web developer position filled.
-
tried using the mac address allow, saved changes and then restarted dhcp server [ not sure is restart is needed ] rebooted the client and still wrong dns in resolv.conf .
maybe the client is asking for and getting the old lease information. is there a place to clear the cache?
-
The client could be remembering it, that varies by OS but it may be in /tmp/ or /var/ somewhere. (I think it's /var/lib/dhclient/dhclient.leases but on FreeBSD it's in /var/db/dhclient/dhclient.leases I think, or thereabouts)
On pfSense the server's lease database is under /var/dhcpd/var/db/ but you can clear individual leases from the GUI by clicking the 'x' next to the lease under Status > DHCP Leases. Failing that, stop the dhcp service, rm the leases files(s), then restart it.
-
I just did a quick test in a VM:
option domain-name "example.com"; option ldap-server code 95 = text; option domain-search-list code 119 = text; default-lease-time 7200; max-lease-time 86400; log-facility local7; ddns-update-style none; one-lease-per-client true; deny duplicates; ping-check true; authoritative; class "000C29DBA30B" { match if substring (hardware, 1, 6) = 00:0C:29:DB:A3:0B; } subnet 192.168.27.0 netmask 255.255.255.0 { pool { deny members of "000C29DBA30B"; range 192.168.27.100 192.168.27.199; } pool { option domain-name-servers 208.67.222.222; allow members of "000C29DBA30B"; range 192.168.27.50 192.168.27.60; } option routers 192.168.27.1; option domain-name-servers 192.168.27.1; }That one MAC address is my test client.
And the Windows client received:
Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : example.com Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physical Address. . . . . . . . . : 00-0C-29-DB-A3-0B Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.27.50 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.27.1 DHCP Server . . . . . . . . . . . : 192.168.27.1 DNS Servers . . . . . . . . . . . : 208.67.222.222 Lease Obtained. . . . . . . . . . : Wednesday, December 26, 2012 3:02:35 PM Lease Expires . . . . . . . . . . : Wednesday, December 26, 2012 5:02:35 PMSo it did receive the expected IP and DNS server from the secondary pool.
-
the client here runs debian wheezy .
there is a fixed dhcp lease in /var/dhcpd/etc/dhcpd.conf on pfsense.
all the rest of settings here look the same.
when i get a chance, I'll try removing the fixed lease , clearing caches , restating network on client…
maybe you could try adding the test client to fixed leases ..
-
after deleting the fixed lease the client got the correct sub pool nameserver.
on our current dhcp server we use 'group' to assign some dhcp options:
group { option ntp-servers 10.100.100.17; next-server 10.100.100.17; host phone30 { hardware ethernet 00:0E:08:19:.....; fixed-address 10.100.199.30; } host phone31 { hardware ethernet 70:81:05:-----; fixed-address 10.100.199.30; } # we have about 20 more devices... }the isc-dhcp-server server runs on Debian wheezy . here is version info:
fbc123 /etc/dhcp # aptitude show isc-dhcp-server Package: isc-dhcp-server State: installed Automatically installed: no Version: 4.2.2.dfsg.1-5+deb70u2I think
maybe fixed leases could be assigned to a group? -
With some more coding changes, perhaps.
Fixed leases do not belong to a pool so no pool-specific settings will apply to them.
Eventually someone could take the pool type settings and apply that to static leases as well, since most all of those settings are also valid for static leases.
But doing the groups thing, though interesting, would greatly increase the complexity of the code on the page, and it's already pretty complicated.
Possible, yes, but unless someone pumps some funding into it, not likely to happen anytime soon.
-
FYI- Input validation was added last week to prevent overlapping pools from being saved. Testing would be helpful there also.
-
I tested multiple DHCP pool for a subnet (LAN) and I noticed that the fixed lease were not anymore handle properly. Only the last one inserted was show in the fixed lease table in the bottom of services_dhcp.php.
Every new insertion made the previous record to be delete.
-
I tested multiple DHCP pool for a subnet (LAN) and I noticed that the fixed lease were not anymore handle properly. Only the last one inserted was show in the fixed lease table in the bottom of services_dhcp.php.
Every new insertion made the previous record to be delete.
On 2.1 or with a 2.0.x patch? (I would expect issues with the 2.0.x patch, it wasn't meant to be used, use 2.1 instead)
-
I tested multiple DHCP pool for a subnet (LAN) and I noticed that the fixed lease were not anymore handle properly. Only the last one inserted was show in the fixed lease table in the bottom of services_dhcp.php.
Every new insertion made the previous record to be delete.
On 2.1 or with a 2.0.x patch? (I would expect issues with the 2.0.x patch, it wasn't meant to be used, use 2.1 instead)
Seems to be fixed by this:
https://github.com/pfsense/pfsense/commit/37c922a6faff0e55db04fb66e43b76180e1c1449 -
Is "Multiple DHCP pools outside of subnet"
Anywhere on the roadmap?
Or is there any smooth way to a DHCP-range outside of LAN interface subnet?
-
Is "Multiple DHCP pools outside of subnet"
Anywhere on the roadmap?
Or is there any smooth way to a DHCP-range outside of LAN interface subnet?
It's closer to being possible, but not going to happen any time soon (maybe 2.2, if someone has the time or funding for it).
There is no way to do DHCP for another subnet on an interface currently. That's a question for another thread, though.
