Ignore DHCP for a group of MAC addresses?

  • Is there any way in pfSense (either manually or via the GUI) to have the DHCP server IGNORE requests coming from AA:BB:CC:*  MAC addresses?  I am having a strange issue and need to do this for troubleshooting purposes…

    thanks guys for any advice.

  • The closest I can think of is to tick Deny unknown clients on the appropriate DHCP server tab and define static mappings for the other clients. (I haven't tried this.)

  • I thought about that but the problem is, then any new devices (e.g. a guest device that wants to connect via wifi) will have to look up its MAC and then have someone log in and assign a static DHCP… not to mention this limits the toal # of devices that can ever connect to about 253.  That's a deal breaker.

  • Bump - there has to be a solution to this, as it stands every time someone plugs in a voip phone, they have to have someone go unplug the pfsense unit first so the DHCP server doesnt reply with the wrong info.  arggghh

  • @luckman212:

    every time someone plugs in a voip phone, they have to have someone go unplug the pfsense unit first so the DHCP server doesnt reply with the wrong info.  arggghh

    1. Put the VOIP phones on a separate network and configure DHCP server to supply the correct information.

    2. Configure the DHCP server to provide the correct information.

    3. Preconfigure the VOIP phones so they don't use DHCP.

    Maybe there are some relevant factors about your network or your VOIP phones that you you haven't told us,

  • Yes, some more information:

    1. voip phones are from another (large and indifferent) vendor and I have no access to change or even inspect their settings.  They are in a 3yr contract with this vendor so I can't realistically suggest switching to another setup.

    2. only single ethernet cable feeding the user so the PCs are "piggybacked" off the phones via ethernet passthru, so I can't separate them on a different switch.

    I think this makes any of those proposed solutions impossible?

  • 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:

    1. isc dhcpd:

    class "phones" {
    match if substring (hardware,1,8) = "00:11:22";

    1. 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 {
          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 {
     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
    and then
    when you're done

    I'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 to 08:00:0f:53:b8:70 via em0
    Feb 27 14:26:38 dhcpd: DHCPREQUEST for ( 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 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  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 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:


  • 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..

  • 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.

  • @luckman212:

    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.

  • If it actually had 16382 items on it, broadcast might (or might not - I'm not sure without trying it) be a bit of an issue - actual number of hosts on it now would fit in a /22, but it was enough of a pain re-addressing everything that I thought long and hard about how far it might grow, and then added a couple of bits to be safe. That net has a larger number of users, and more "personal devices" on it - when it was a /24, I ran out of DHCP addresses for 85 users when users started to have a computer, and a phone, and an iPod (or equivalent), and an iPad or other tablet, and an e-book-reader, and who knows what else all looking for an address. Not every user, but enough.

    My crystal ball said go absurdly big, but still didn't think I needed to go all the way to a /16. If that one was a /22, I'd be getting close already. The one that's a /22 is an inherently smaller number of users, but I quadrupled it anyway when I had to re-address it for other reasons, as the other one showed me the writing on the wall. I'm pulling for IPv6 to finally deliver the promised land one of these days…

    <edit>Similar to Stan, I use the increased address space to apply some logic to my addresses. I used to have that on a /24, but as things grew over 15 years it became harder to manage as the reserved addresses for this had to be used so that would fit. I have both "types of service" and physical location prefixes.</edit>


© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy