Ignore DHCP for a group of MAC addresses?
-
The usual way to do that with PCs plugged in via the phones is to configure the phones to tag their traffic on a VLAN, and only have that one DHCP server on the VLAN for the phones.
There is no option to ignore a group of MAC addresses, closest is the deny unknown clients option mentioned. That's true of every DHCP server, it just isn't possible. The only other alternative is to configure whatever DHCP options the phones require so they don't have to hit their own DHCP server, which may or may not be a reasonable solution depending on specifics.
If you can't change the phones to tag their traffic, and can't plug the PCs in elsewhere, and can't consolidate to a single DHCP server, you have an unsolvable problem regardless of what software you use.
-
I can think of two ways, but I'm not sure if they're doable from pfsense's webGUI:
- isc dhcpd:
class "phones" {
match if substring (hardware,1,8) = "00:11:22";
}- ipfw L2 filtering (enabled in pfsense)
do a man ipfw and read the MAC
-
I don't think you can disable handing out leases with classes though can you?
ipfw blocking only DHCP requests by MAC address match could work, but have to be hacked in manually. That doesn't address the fact that the PCs on occasion probably get a lease from the phones' DHCP server, which may be undesirable or problematic.
-
iirc isc dhcp can deny based on class e.g.:
pool {
range 192.168.2.50 192.168.2.75;
allow members of "mypcs";
deny members of "phones";
}wrt the ipfw L2 filtering, I suppose PCs could occasionally get a lease from the phones' DHCP server (assuming it isn't configured to only respond to certain clients), but ipfw L2 might again be configured to forward UDP 67/68 traffic to it from the phones' MAC-addresses only (ipfw allows wildcard MAC matching e.g. MAC any 00:11:22:33:00:00/32). However I should note that haven't tried this.
-
Hmm interesting responses, I appreciate the help! After some more digging, it seems there might be a solution, something along the lines of adding the following clause to my dhcpd.conf
class "mitel" {
match if substring(hardware,1,8) = 08:00:0f;
ignore booting;
}pool {
range 192.168.2.10 192.168.2.99;
deny members of "mitel";
}I haven't tested this but I think that it might work. But when I logged into the console and tried to vi /etc/inc/services.inc when I went to write out the file I got:
Error: services.inc: Read-only file system.Do I need to remount the filesystem as r/w? Sort of scared to do this on an embedded system that I am not physically standing next to.
edit: well I found out how to get the filesystem into rw mode. The commands are
/etc/rc.conf_mount_rw
and then
/etc/rc.conf_mount_ro
when you're doneI've made my edits, rebooting the box now….stay tuned :-\
-
Hmm that hasn't gone well. It seems that there's no /etc/dhcpd.conf or /var/dhcpd/etc/dhcpd.conf after rebooting the box. I think maybe dhcpd.conf is generated from scratch during each reboot? Not sure, I need to dig deeper… arggh.
??? -
I've just tested it and it works.
In your case, use
class "mitel" {
match if ( substring(hardware,0,4) = 01:08:00:0f );For your tests, you'll need to manually edit /var/dhcpd/etc/dhcpd.conf on the pfsense box, kill dhcpd and restart it from command-line. Note that the /var/dhcpd/ files are regenerated and overwritten on each reboot.
-
I went about this a slightly different way, that doesn't require manual killing/restarting dhcpd. I inserted the following clause right before the "{$custoptions}" line (~line 136) in /etc/inc/services.inc so this way it gets preserved even if I make changes via the GUI. Of course this won't survive an upgrade so I'll just have to remember to re-patch after any upgrades. Hopefully one day the GUI will have a box for easier customizing of dhcpd.conf …
class "mitel" {
match if binary-to-ascii(16,8,":",substring(hardware,0,4)) = "1:8:0:f";
ignore booting;
}Is my match string correct? I have seen some examples omit the whole binary-to-ascii conversion step but I was following the notes of Michael Lucas (who wrote a BSD book) at http://blather.michaelwlucas.com/archives/962
-
Okay, the above isn't working for me. I am not at the site to test hands on but my contact there said he rebooted a phone and it failed to boot. I checked the DHCP leases and I actually don't see any entries for the phone's MAC address (that's a good thing I suppose) so DHCPd isn't handing out an IP. But when I go to System Log it is overflowing (pages and pages) of
dhcpd: parse_option_buffer: malformed option vendor-class. <unknown>(code 1027): code tag at end of buffer - missing length field.
Any more ideas? Should I try to packet filter / firewall this so no traffic whatsoever from the phones ever reaches the pfSense box? (not sure how to even go about that)
EDIT: sorry, actually upon further inspection, I looked at the DHCP tab of Logs and I see that the daemon is actually handing out an IP – so my "ignore booting" is apparently not having the desired effect. See below:
dhcpd: DHCPNAK on 10.161.157.158 to 08:00:0f:53:b8:70 via em0
Feb 27 14:26:38 dhcpd: DHCPREQUEST for 10.161.157.158 (10.167.0.32) from 08:00:0f:53:b8:70 via em0: wrong network.</unknown> -
Well, as I mentioned in my previous post, the isc dhcpd method I suggested seems to work in my test setup. The logfile now includes a lines like DHCPDISCOVER from <excluded mac="" addr="">via em1: network 192.168.150.0/24: no free leases.
The ipfw L2 method should also work in theory, but I haven't tested it yet.</excluded>
-
Actually just looking again at this and it looks like the phone is getting a 10.161.157.158 address from somewhere (not my pfSense box for sure) so it appears maybe the "ignore booting" directive was working after all(?). But again not sure why the phone then sends a DHCPREQUEST for 10.161.157.158 to pfSense, perhaps that was the last IP it had cached in its memory so it's trying to reclaim it – which pfSense correctly responds "wrong network" to.
re: ipfw, I scoured the whole GUI and couldn't find anywhere to configure this-- is this going to be another hack via CLI? I saw some posts about the Captive Portal system making use of ipfw, do I need to enable Captive Portal first??
-
Have you considered asking pfsense's commercial support to add this feature ? Doing a little google-ing one finds out that it is not uncommon to want dhcpd to withhold leases to certain MAC addresses, especially in larger environments.
A case similar to yours can be found here :
The infrastructure department doesn't want to pre-configure the phones when they are delivered (which is very comprehensible, because they would have to administrate several thousands of them), so the phones don't know anything about a local configuration. Connecting the phones to a special "VLANned" port of the floor switch is not possible, either. The reason is that the phones contain a built-in switch which allows to connect computers to it to avoid that the phones "block" additional network wall sockets, as cables are rare in some office rooms.
So what they are doing is the following: The phones shout out an DHCP request. Our institute's DHCP (Mac OS X) should stay quiet and ignore it. The DHCP of the phone infrastructure department (which is present in every subnets of the institutes due to a special switch configuration) answers and does "AVA" (automatic VLAN assignment). That means: Their DHCP forces the telephones to go then into a special phone VLAN. The VLAN termination is then done in the phones (not in the floor switch), so a computer which is connected to the switch that is embedded into the phones won't be in the telephone VLAN, but stays in the institute's LAN.
-
I found a solution, I had to enable the directive
not authoritative;
What this does is stop dhcpd from sending DHCPNAK responses to the requesting device, allowing it to receive additional replies from the other server on the network.
I did this by editing /etc/inc/services.inc ~line 150:
$dhcpdconf .= "authoritative;\n"; → $dhcpdconf .= "not authoritative;\n";So far so good. :)
Would be wonderful to have an option to control this via the GUI. I see the include file already "supports" this because it has the following clause which queries the "disableauthoritative" variable:if(!isset($dhcpifconf['disableauthoritative']))
-
I hope a GUI option to control this flag might be added for pfSense 2.1
-
I'm running all ISC DHCP servers on Linux, including largest one - for ~500 hosts.
I never thought that this option:
not authoritative;
has that meaning.So there can be 2 or more DHCP servers running on same subnet? Doesn't it cause conflicts?
Since additional connected DHCP-enabled devices always caused problems I was about to ALLOW only authorized DHCP server on the network (by setting specific options on every switch)..I run it on Linux, since I can set every option separate for every host, for example: different gateways, different DNS servers, next-server for TFTP boot etc..
-
Just a quick heads-up that such a feature (http://redmine.pfsense.org/issues/2241) has been implemented.
Commits:
https://github.com/bsdperimeter/pfsense/commit/1f1a08c85b7e8ddc6473795534ed5422a2c5aaaf
https://github.com/bsdperimeter/pfsense/commit/80d30a83463f3ee8160bbd9b38cd2f2f510560d7 -
I would like to comment: Thank you for this patch! :), but… :( I am not sure the patch on issue #2241 does really address the problem I have outlined here. I see it adds a "MAC address control" area to the GUI of DHCP but it still doesn't seem to add a way to configure the "not authoritative" flag that is so crucial to this working. As far as I can tell, my manual edits to /etc/inc/services.inc would still be required. I added a comment to the issue to request again a checkbox for this.
-
this limits the toal # of devices that can ever connect to about 253. That's a deal breaker.
Just to address this (false) assumption based on the default configuration:
You can have 16,777,214 devices (assuming NAT - thats a /8 or Class A - 10.X.X.X). Nothing (other than lots of stuff including pfSense defaulting to class C, and usually 192.168.1.X (sometimes .0.X or .100.X) says you have to stick to a /24 subnet on NAT. I'm currently running a /22 (1022) and a /18 (16382) precisely because 253 became a problem. Other than learning a new subnet mask, and possibly gateway addresses, nothing to it. I also chose to shift to the class B space when doing this, but didn't feel I really needed 65534 spaces in any timeframe I could imagine, so I picked sizes that seemed likely to be (more than) adequate for the foreseeable future for my nets.
-
Just curious, on a /18 (that's pretty big :o ) how do you deal with broadcast traffic? That doesn't become a problem?? Also, yes I understand that using larger subnets allows for >253 devices but it still doesn't solve the problem of having to enter/manage hundreds of MAC addresses – which is not scalable. I still think adding some simple conf options to the DHCPd GUI page would quickly solve this issue. If I knew more about how to contribute to the project I would probably try to author this patch myself.
-
Data entry can be cut way back by using the https://pfsense/status_dhcp_leases.php page to automatically create the static mappings. I only had to type a few MAC addresses for devices that it was easier to do that for than to find and power up.
I'm using a /22 from the old Class B range myself, I logically divided stuff up into ranges just to make things easy to remember.
172.16.0.X = Servers
172.16.1.X = Wired workstations / devices
172.16.2.X = Wireless laptops / tablets
172.16.3.X = DHCP (usually vacant)With the equivalent of four Class C blocks I'm not having any issues with broadcasts or scanning looking for services.
