Ignore DHCP for a group of MAC addresses?

luckman212

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

wallabybob

@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,

luckman212

Yes, some more information:

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

cmb

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.

dhatz

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

cmb

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.

dhatz

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.

luckman212

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 done

I've made my edits, rebooting the box now….stay tuned :-\

luckman212

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

dhatz

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.

luckman212

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

luckman212

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>

dhatz

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>

luckman212

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??

dhatz

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.

luckman212

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']))

luckman212

I hope a GUI option to control this flag might be added for pfSense 2.1

toomeek

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

dhatz

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

luckman212

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.