DHCP filter by MAC vendor (first octets)

#1

There have been a few similar requests to this, but I do not think they actually asked for the correct feature, which may be why those requests were not acted on.
In many routers it is possible to set a DHCP server on a subnet with a filter based on leading octets of the MAC address (usually the forst 6 to filter by vendor).
The purpose is to make the DHCP server respond ONLY to devices matching the filter (i.e. 00:15:65 is Yealink IP phones).
Now, you may say “you can do this with DHCP reservations”, but that is not correct, because the this is actually about NOT responding to devices that do not match.
In other words, if we could do specific reservations and say “and do not respond to any other devices”, then that would work, but would be a royal pain in the ass for large installations - the one I just did was over 150 phones, so I would really hate to have to enter all those mac addresses just for this purpose.
The reason we need this feature is that the customer has shared cabling for phones and PCS, and it all has to be on the same untagged network because they have stupid so-called “smart” switches that will not allow us to do a VLAN,
We needed to have the peplink DHCP serve only the phones, and their sonicwall serve the PCs. No problem telling the sonicwall to NOT serve 00:15:65:::** but not possible to set the peplink to only serve that

#2

I would also appreciate having this feature.

#3

Does the sonic wall have an option to forward the requests that it isn’t going to serve?

#4

forward? I don’t think so. but like most routers it can ignore them. FYI - in most cases where we need this, the pepwave is actually “next to” the sonicwall, not in front of or behind it.

i.e.
Internet modem=>sonicwall WAN (serving PCs)
internet modem=>pepwave WAN (serving phones)

We are not a general IT shop - just IP phones. When we (and sometimes the customer) have no access to the sonicwall, or it is running 300 year old firmware…better to just bypass it for VoIP.

So - end result is two gateways on same network (obviously, when we CAN use VLANs we do, so it is two networks on one physical network). Different gateway IPs. PCs served by the Sonicwall, phones served by pepwave

#5

Is it possible to set up a reservation for each phone and ONLY have enough addresses in the pool? It isn’t ideal, but you can do some bulk loading for Mac/IP reservations.

Just a thought

#6

Hmm. that could work. would be a real pain when there are a lot of phones, but would work.

#7

I want to raise this issue again - I just ran into this need for a new 33 location customer. Due to existing network restrictions that are not going to change we cannot use VLAN tagging on the customer network, but the phones have to be on a separate subnet and use the pepwave as their gateway.
The customer’s physical network will have two gateways - their evil SonicWall-of-death-to-VoIP and the pepwave.
Now, because there is no way to apply a filter tot he DHCP server in the pepwave I will have to use static IP addresses on the 15 phones at each of 33 locations. That sucks.
My request here was to be able to add a mac address leading octets filter and some simple deny/allow rules on the dhcp server.
i.e.
DENY ALL
ALLOW 00:15:65:XX:XX:XX (yealink)
ALLOW 12:34:56:AA:BB:CC (some specific device)
you CAN do this on the sonicwall, so we can do a DENY 00:15:65:XX:XX:XX there
Result:Sonicwall answers all but yealink, pepwave answers only yealink.

#8

Dear Pepllink Team,

I’ve seen multiple threads asking for MAC filtering. Please implement it. I’m in the same boat as many others in that we have 7+ Peplink devices for an org and I need to only allow authorized devices to connect. Firewall rules may work but this means I have to manually add every rule to every firewall (staff and therefore their unauthorized personal devices rotates offices daily).

It would be ideal to have a simple “block” option from the DHCP clients list vs having to navigate multiple pages to add one MAC to every firewall in the org. Please please please add this. Additional filter functionality as described by OP would be great too.

Regards

#9

Thanks for your persistence guys. We will look into this and respond.

1 Like
#10

MAC filtering in general is a poor practice (in my opinion) as anyone can spoof a MAC and it’s rather easy to do so. I’d recommend doing a mass configuration of the devices via their recommended best practices (hopefully not MAC based) to either statically assign IPs to phones or another approach… potentially just auth-ing phones via software rather than if they get an IP or not.

#11

Agree its Poor practice - I’d never design a network from scratch that way, but the issue we have as MSPs is working within existing customer networks (that don’t tend to be designed well) as quickly as possible since time is money.

You’re not always going to get permission (or have the time) to rip and reconfigure a customers network to add some VoIP phones.

MAC filtering then can be a very useful tool for MSPs - even if its not perfect on paper.

3 Likes
#12

We need MAC whitelististing please. How can we send out a router that anyone could plug any device into and use our network? This is a must need

#13

There is another key use for this, other than security. If you only want the DHCP server to be responding for a given type of device (like just for Yealink IP phones), then this is the only way to do it.

1 Like
#14

…that sounds like “security” to me as someone can just spoof a Yealink MAC and obtain an IP from your DHCP server.

#15

Eh - this is not about “we MUST only respond to specific devices”. If it was, we would use static IPs. This is about “We only WANT to serve IPs to a specific class of devices because it makes our life easier”

#16

We could also really use this. A MSP plugged in a laptop the the phones vlan , got a ip address since it was in access mode port, and then used a lot of data as the phones were configured to go over cellular. If we could implement a dhcp filter for the vlan to only respond to the first 6 of the mac say for grand stream and yealink this would have solved it.

#20

@Jonathan_Pitts and @jmpfas

Request filed and Engineering team is considering the feasibility for the requested feature. I will post again if get more information from Engineering team.

1 Like