Getting DHCP Leases - although Deny unknown clients is active

  • 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

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

  • 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

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

  • LAYER 8 Global Moderator

    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 ( 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. . :
      Subnet Mask . . . . . . . . . . . :
      Default Gateway . . . . . . . . . :
      NetBIOS over Tcpip. . . . . . . . : Enabled

    So I then added dhcp reservation for its mac in my normal lan segment
    00:0c:29:07:3c:fd  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. . . . . . . . . . . :
      Subnet Mask . . . . . . . . . . . :
      Lease Obtained. . . . . . . . . . : Friday, March 27, 2015 12:25:19 PM
      Lease Expires . . . . . . . . . . : Friday, March 27, 2015 2:25:19 PM
      Default Gateway . . . . . . . . . :
      DHCP Server . . . . . . . . . . . :
      DNS Servers . . . . . . . . . . . :
      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, etc..

    I am running 2.2.1 amd64


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


    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.


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

    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;
    	option host-name "Davis-PC_WiFi";

    If I connect to the subnet that has 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 netmask {
    	pool {
    		deny unknown-clients;
    	option routers;
    	option domain-name-servers;
    	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:

    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…

Log in to reply