Getting DHCP Leases - although Deny unknown clients is active

turtle

Hello

following situation

pfsense version 2.1.3 HA setup
DHCP server active, deny unknown clients active
2 vlans, vlan5 and vlan 3
PC1 has a fixed dhcp entry set in vlan 3.

But PC1 also gets a dhcp lease offered (from dhcp range) in Vlan5 .. if plugged on vlan5 port !!

if i remove the fixed dhcp entry in vlan3,

the dhcp discover in vlan 5 failes, and no dhcp lease is offered.

Why does this happen? and how can i prevent that devices with fixed entrzs in other vlans, get dhcp leases in my main vlan (vlan5)

thank you

muswellhillbilly

Sounds like you may have two VLANS which can see one another, though you'd need to post more information for anyone to give a reasonable guess. How have you subnetted the two VLANS? Have you set up a separate DHCP service for each one? You'll need to post the DHCP config for each VLAN, showing the ranges as well as any static address mappings you have.

turtle

vlan 5 has access to every other vlan

vlan3 is restricted and has only internal access.

they both have their own /16 ip range, and own dhcp range

muswellhillbilly

Ok, you'll need to provide a bit more information than that. I suggest you post screenshots of your DHCP configs for each VLAN on the pfSense box as well as the network addressing and subnetting for each internal interface. Otherwise we'll be going nowhere with this in a hurry.

johnpoz

really /16 range.. talk about segment IP mismanagement ;)

Sounds like it works with a shared database, the client (mac) is known, from your vlan3 dhcp reservation. So I duplicated this.. I setup my dmz (192.168.3.0/24) zone to deny unknown.. I made sure there were no old leases for this mac, etc..

I then rebooted the vm, and does not get a IP, just 169.254

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter
Physical Address. . . . . . . . . : 00-0C-29-07-3C-FD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IPv4 Address. . : 169.254.83.204(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled

So I then added dhcp reservation for its mac in my normal lan segment 192.168.1.0/24
00:0c:29:07:3c:fd 192.168.1.22 testdhcpdeny

I then tried a renew on the box that is in the dmz segment.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : local.lan
Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter
Physical Address. . . . . . . . . : 00-0C-29-07-3C-FD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.3.109(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Friday, March 27, 2015 12:25:19 PM
Lease Expires . . . . . . . . . . : Friday, March 27, 2015 2:25:19 PM
Default Gateway . . . . . . . . . : 192.168.3.253
DHCP Server . . . . . . . . . . . : 192.168.3.253
DNS Servers . . . . . . . . . . . : 192.168.3.253
NetBIOS over Tcpip. . . . . . . . : Enabled

So yeah seems to be a bit of shared listing, etc. If pfsense has a static reservation for that mac in another scope, it seems to hand out an IP in different scope that is set to deny. Not sure if this is fixable? Should at min reword the text by the deny to state any reservation not just the ones below that only show reservations in that scope.

Deny unknown clients
If this is checked, only the clients defined below will get DHCP leases from this server.

But on my dmz there is no static mappings, but on my lan segment there is a static mapping for that mac on IP 192.168.1.22, etc..

I am running 2.2.1 amd64

phil.davis

https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf&sektion=5&apropos=0&manpath=FreeBSD+10.1-RELEASE+and+Ports#ALLOW_AND_DENY_WITHIN_POOL_DECLARATIONS

When declaring permit lists for address allocation pools, the following
syntaxes are recognized following the allow or deny keywords:

known-clients;

If specified, this statement either allows or prevents allocation from
this pool to any client that has a host declaration (i.e., is known).
A client is known if it has a host declaration in any scope, not just
the current scope.

unknown-clients;

If specified, this statement either allows or prevents allocation from
this pool to any client that has no host declaration (i.e., is not
known).

So this is documented behavior. e.g. one of my "host" statements in my dhcpd.conf is:

host s_opt2_4 {
        hardware ethernet 00:1f:3c:14:b1:6e;
	fixed-address 10.49.213.1;
	option host-name "Davis-PC_WiFi";
}

If I connect to the subnet that has 10.49.213.1 inside it, then I am given that IP address. If I connect to some other LAN-style subnet/interface on my pfSense that even has "deny unknown hosts" specified like:

subnet 10.49.208.0 netmask 255.255.252.0 {
	pool {
		deny unknown-clients;
		range 10.49.211.0 10.49.211.254;
	}

	option routers 10.49.208.250;
	option domain-name-servers 10.49.208.250;

	option custom-lan-0 07:10:C0:A8:0A:31:D4:01;
}

I get an IP address in the specified range of that pool, because I am a "known" host.
That seems a shame! It is NOT supported to simply list hosts within a subnet{} scope - which would be an easy way to tell it that certain hosts were just restricted to that subnet.

The way to do it is to use classes and sub-classes:
https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf&sektion=5&apropos=0&manpath=FreeBSD+10.1-RELEASE+and+Ports#SUBCLASSES
https://thelowedown.wordpress.com/2008/01/24/using-dhcp-client-classing/
http://serverfault.com/questions/472618/how-do-i-assign-hosts-to-classes-in-isc-dhcpd

The way the pfSense GUI is organised, you already add static-mapped entries by interface (subnet) anyway. So the pfSense config knows which static-mapped hosts belong to which subnet. The PHP code that generates dhcpd.conf could make "class" and "subclass" statements that put all hosts for an interface into one class, then if "deny unknown clients" is selected on an interface, actually put an "allow members of "interface-xyz";" statement in the pool for that subnet. That will allow just those specified on the interface, and stop any unknown and any that are known from other interfaces.

I guess nobody should be depending on the current more liberal behavior, because the GUI description already says "If this is checked, only the clients defined below will get DHCP leases from this server." - so the current behavior is technically a bug and should be tightened up to match what is claimed on the GUI.

There are some situations where I would like this to work as advertised, so I will raise a redmine issue and have a look…