Deny unknown clients, broke?
-
Once you put a mac into a reservation. Its a KNOWN host.. If you move it to a different dhcp server that has leases available it will be able to get a IP from the dhcp server.
If you know longer want this box to be known, then you need to remove it from all dhcp servers listings, etc.
-
Once you put a mac into a reservation. Its a KNOWN host.. If you move it to a different dhcp server that has leases available it will be able to get a IP from the dhcp server.
If you know longer want this box to be known, then you need to remove it from all dhcp servers listings, etc.
Sorry, but I can't follow your explanation. When I have a reservation for a mac and remove it from the reservation list of this DHCP server, it should not get an ip from that DHCP server again when I have enabled "Deny unknown clients"!
-
So you don't have it listed anymore in any other dhcp server? Is that mac listed in any of your other dhcp servers.. If so it becomes a KNOWN device - the wording should be reflected to state that. Unless its planned to be fixed.. The issue is uses a common file for all your dhcp servers. If that mac is listed in any of the dhcp servers - see all of mine then yes it can get a dhcp lease from a different dhcp server if you move the client to that layer 2 network. There was a thread about this a while back..
For example have a reservation for it in lan and my wlan. And I delete the lan, it wold still be able to get a lan IP from that dhcp server, since it has a reservation in wlan and becomes a known host.
You also need to make sure there is NO lease still around for that client, it yeah it will be able to renew the lease.. Make sure you clear all old leases up for a client that you no longer want to be able to get a lease.
-
So you don't have it listed anymore in any other dhcp server? Is that mac listed in any of your other dhcp servers..Yes, it has been moved over to another subnet/DHCP server.
If so it becomes a KNOWN device - the wording should be reflected to state that. Unless its planned to be fixed.. The issue is uses a common file for all your dhcp servers. If that mac is listed in any of the dhcp servers - see all of mine then yes it can get a dhcp lease from a different dhcp server if you move the client to that layer 2 network. There was a thread about this a while back..
Ok clear so then it's a bug isn't it?
For example have a reservation for it in lan and my wlan. And I delete the lan, it wold still be able to get a lan IP from that dhcp server, since it has a reservation in wlan and becomes a known host.
You also need to make sure there is NO lease still around for that client, it yeah it will be able to renew the lease.. Make sure you clear all old leases up for a client that you no longer want to be able to get a lease.
Ok will try it thanks for your explantion.
-
"Ok clear so then it's a bug isn't it?"
No its not a bug.. Its how it works.. I would have to dig up that other thread to recall if there was any idea or way of changing the way it works.. You will notice there is only 1 dhcp conf file that has your reservations in it.. From the manual of the dhcpd.conf it states
"An unknown client is simply a client that has no host declaration. "
"A client is known if it has a host declaration in any scope, not just the current scope. "
https://linux.die.net/man/5/dhcpd.confIf you have a reservation in another dhcp server then that host has a declaration.. And they are all in the same dhcpd.conf file.. /var/dhcpd/etc/dhcpd.conf
What exactly are you trying to accomplish??? Not giving an IP via dhcp is not a valid security method.. While you might use deny unknown hosts for some sort of control method. Its not valid security in keeping a client off a network. For starters it is trivial to change a clients mac.. What what exactly are you wanting to accomplish and we can go over actual valid ways to accomplish that.
-
"Ok clear so then it's a bug isn't it?"
No its not a bug.. Its how it works.. I would have to dig up that other thread to recall if there was any idea or way of changing the way it works.. You will notice there is only 1 dhcp conf file that has your reservations in it.. From the manual of the dhcpd.conf it states
"An unknown client is simply a client that has no host declaration. "
"A client is known if it has a host declaration in any scope, not just the current scope. "
https://linux.die.net/man/5/dhcpd.confIf you have a reservation in another dhcp server then that host has a declaration.. And they are all in the same dhcpd.conf file.. /var/dhcpd/etc/dhcpd.conf
Thanks for the explantion, if you have that thread it would be great.
What exactly are you trying to accomplish??? Not giving an IP via dhcp is not a valid security method.. While you might use deny unknown hosts for some sort of control method. Its not valid security in keeping a client off a network. For starters it is trivial to change a clients mac.. What what exactly are you wanting to accomplish and we can go over actual valid ways to accomplish that.
I was sloppy and didn't remove the password after porting a device from one AP to another. Then I got confused that it was still getting a IP in the previous subnet range. So in this case it helped me, confronting me with the fact that I didn't remove the password ;)
-
Here is the thread I was thinking of
https://forum.pfsense.org/index.php?topic=91391But its come up a few times.. Check with @phil.davis from that thread he mentions he was going to put in a redmine about maybe doing it a different way..
-
If you want to restrict by MAC per interface, use the MAC allow or deny boxes and not "deny unknown clients".
That doesn't scale very well, but it will give you more fine-grained control over who can pull from where.
-
Here is the thread I was thinking of
https://forum.pfsense.org/index.php?topic=91391But its come up a few times.. Check with @phil.davis from that thread he mentions he was going to put in a redmine about maybe doing it a different way..
Thanks for pointing that one out me :)
-
If you want to restrict by MAC per interface, use the MAC allow or deny boxes and not "deny unknown clients".
That doesn't scale very well, but it will give you more fine-grained control over who can pull from where.
Thanks, I never thought of that one!!
