PfSense2 - Multi LAN DHCP problem
-
We have 3 subnets (10.10.10.x, 10.10.11.x, 10.10.12.x) each having DHCP set up. We have each of these DHCP subnets set up with Deny unknown clients and Enable Static ARP entries so that only REGISTERED machines can receive IP addresses and connect to the system. Unfortunately, it appears that if a machine is registered with the 10.10.10.x subnet, the 10.10.12.x subnet will see it and hand out the 'open' DHCP address it has available. This then makes that machine unable to connect to the network.
The DHCP system insists on having at least one IP address available to hand out and I've not been able to find any way to block a machine that is configured on one of the DHCP servers from picking up the 'open' address on a different DHCP server. This particular quirk makes the whole system unusable. Does anyone know how to fix this or work around it? -
The DHCP system insists on having at least one IP address available to hand out and I've not been able to find any way to block a machine that is configured on one of the DHCP servers from picking up the 'open' address on a different DHCP server.
I tried to configure a pfSense DHCP server with Deny unknown clients enabled and an empty range but couldn't. It complained about the empty range. Either Deny unknown clients means something other than what you and I think it means or this is a bug (possibly to work around a bug in dhcpd). It seems to me that specifying a range and enabling Deny unknown clients shouldn't be allowed.
As it stands it appears Deny unknown clients really means "Deny unknown clients after the first".
-
You can setup Deny Unknown Clients and create static mappings with the IP address field blank.
You might want to look into MAC address filtering on your switch if you don't want machines to be moved around.
-
I still have not found any way to get around the basic problem here. I either need to have DHCP active with no pool addresses available to hand out or else have the DHCP server reply ONLY when the request comes from a machine that is registered ON THAT NIC. Right now the DHCP monitoring NIC3 sees a request, checks and sees that the MAC is registered on NIC1 and proceeds to hand out a DHCP address for NIC3. This means that particular machine cannot connect because it's MAC/IP combination does not match up with what is registered under NIC1.
It continues getting even worse because if the DHCP hears a request on NIC3, finds the client is registered on NIC1 but has no available pool addresses for NIC3 it sends back an error message that there is no IP available.
I have thought of one possibility but do not know how to check it out. We have been testing this with a limited number of machines (naturally). Is it possible that pfSense (or more likely, the underlying BSD) is storing the information for a client machine when it attaches through one NIC and then recalling that information when it gets moved over to a different NIC as we test the functioning of the various parts?
-
The way our GUI works there probably isn't a way around that.
You are telling it to deny unknown clients, but to the DHCP daemon any static mapping is in fact a known client.
If you have static ARP enabled though, even if the client pulls an IP it shouldn't be able to talk to (or beyond) the firewall since it would not match the static ARP entry. It may be able to talk to other things in its subnet though because it would be up to the switch to filter that.
If you really want to lock things down that much you should be locking down at layer2. Even if you cut the clients off from DHCP there is nothing stopping them from manually configuring an IP address on the other network(s) and bypassing any firewall restrictions to reach other things in that subnet without more protection at layer 2 from your switch.
-
The way our GUI works there probably isn't a way around that.
You are telling it to deny unknown clients, but to the DHCP daemon any static mapping is in fact a known client.
If you have static ARP enabled though, even if the client pulls an IP it shouldn't be able to talk to (or beyond) the firewall since it would not match the static ARP entry. It may be able to talk to other things in its subnet though because it would be up to the switch to filter that.
If you really want to lock things down that much you should be locking down at layer2. Even if you cut the clients off from DHCP there is nothing stopping them from manually configuring an IP address on the other network(s) and bypassing any firewall restrictions to reach other things in that subnet without more protection at layer 2 from your switch.
FYI, I was using this same scenario up until version 2.0.1.
I have two physical interfaces, LAN and PHONE. I have a DHCP server enabled on both and "Deny Unknown Clients" checked on the PHONE interface. I have static mappings for both interfaces, but as of 2.0.1, a static mapping on the LAN tab allows a machine to pull an IP address from the PHONE tab pool.
Perhaps I had a happy coincidence of things to make it work the way I wanted, but it was definitely working for months until I upgraded to 2.0.1 a few days ago.
