Static IP still assigned to host despite being removed from DHCP Static Mapping



  • What I did?
    1. Created VLAN 1100.
    2. Enabled DHCP Server on this interface.
    3. Checked "Deny unknown clients" and "Enable Static ARP entries"
    4. Added a DHCP static mapping with static IP for a machine.
    5. Machine got assigned the IP successfully.
    6. Removed the static mapping.
    7. After 3 days, I connected the machine and was able to get the ip previously assigned.

    I expected the machine not to be assigned an IP but this was not the case.


  • Netgate

    Is the static mapping inside your DHCP pool?

    ISC DHCP is pretty good about assigning the same IP address to the same MAC address until some other MAC address has been assigned the same IP.  The dormant assignment history can stick around for a long time if you don't have enough unique MAC addresses requesting IPs so the pool wraps.



  • It is outside the pool.

    So this is an expected behavior? Is there any workaround?
    Assuming someone from my company leaves, I will then remove their static mapping. If they then manage to get access to my network, they will be able to get an IP.


  • Netgate

    Umm, see if you can delete the lease in Status > DHCP Leases?? There's a button at the bottom to show all.

    If not you might have to manually delete it from /var/dhcpd/var/db/dhcpd.leases

    After that's gone it should get an address out of the pool.


  • Rebel Alliance Global Moderator

    "If they then manage to get access to my network, they will be able to get an IP."

    With the machine that I would assume you would take from them, since they are no longer with the company?  This a BYOD place?  And once they are let go, they would still have physical access to access the network.  Wouldn't you also disable their account anyway?

    While it seems to be a big of bug/feature - not sure I understand your actual use for it.  Seems like a pretty lame security layer.  So you setup static arp and IP leases for every single device on your network - just so that if they leave and still come back on your network with the same device they wont get an IP?



  • Something isn't going great here.

    I have an iDevice (featuring 0c:77:1a:2b:13:35), and it obtained an IP from by LAN DHCP Pool - 192.168.1.51

    I put the MAC of this iDevice on the static lease list ( DHCP Static Mappings for this interface. ) with a new IP, outside the DHCP pool.
    I checked the "Deny unknown clients" checkbox on top of the page.
    The DHCP server restarted.

    On my iDevice, I forced a DHCP lease renewal.
    It obtained the IP I assigned on the static lease list. So far, so good. My iDevice was connected.

    Logs:

    1. 04-29-2015 09:40:02 Local7.Info 192.168.1.1 Apr 29 09:40:12 dhcpd: DHCPREQUEST for 192.168.1.51 from 0c:77:1a:2b:13:35 via fxp0: lease  192.168.1.51 unavailable.

    2. 04-29-2015 09:40:02 Local7.Info 192.168.1.1 Apr 29 09:40:12 dhcpd: DHCPNAK on 192.168.1.51 to 0c:77:1a:2b:13:35 via fxp0

    3. 04-29-2015 09:40:02 Local7.Info 192.168.1.1 Apr 29 09:40:12 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0

    4. 04-29-2015 09:40:02 Local7.Info 192.168.1.1 Apr 29 09:40:12 dhcpd: DHCPOFFER on 192.168.1.29 to 0c:77:1a:2b:13:35 via fxp0

    5. iDevice wants again 192.168.1.51

    6. pfSense says: No way !!

    7. My iDevice give up asling 192.168.1.51 - it asks for any aviable IP.

    8. pfSense gives 192.168.1.29 - as instructed by my static lease list.
      All is well.

    Now, I deleted (removed) the line that referenced my iDevice from the static lease list.
    The DHCP server restarted.

    I renewed the lease on my iDevice.
    This was the result:
    04-29-2015 09:49:24 Local7.Info 192.168.1.1 Apr 29 09:49:34 dhcpd: DHCPREQUEST for 192.168.1.29 from 0c:77:1a:2b:13:35 via fxp0: unknown lease 192.168.1.29.
    04-29-2015 09:49:26 Local7.Info 192.168.1.1 Apr 29 09:49:36 dhcpd: DHCPREQUEST for 192.168.1.29 from 0c:77:1a:2b:13:35 via fxp0: unknown lease 192.168.1.29.
    04-29-2015 09:49:28 Local7.Info 192.168.1.1 Apr 29 09:49:38 dhcpd: DHCPREQUEST for 192.168.1.29 from 0c:77:1a:2b:13:35 via fxp0: unknown lease 192.168.1.29.
    04-29-2015 09:49:32 Local7.Error 192.168.1.1 Apr 29 09:49:42 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:49:34 Local7.Error 192.168.1.1 Apr 29 09:49:44 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:49:36 Local7.Error 192.168.1.1 Apr 29 09:49:46 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:49:41 Local7.Error 192.168.1.1 Apr 29 09:49:51 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:49:49 Local7.Error 192.168.1.1 Apr 29 09:49:59 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:49:58 Local7.Error 192.168.1.1 Apr 29 09:50:08 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:50:06 Local7.Error 192.168.1.1 Apr 29 09:50:16 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:50:15 Local7.Error 192.168.1.1 Apr 29 09:50:24 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases
    04-29-2015 09:50:23 Local7.Error 192.168.1.1 Apr 29 09:50:32 dhcpd: DHCPDISCOVER from 0c:77:1a:2b:13:35 via fxp0: network 192.168.1.0/24: no free leases

    This log says:
    My iDevice wants 192.168.1.29 from the DHCP server.
    pfSense isn't even replying …...
    My iDevice panics, starts spamming DHCPDISCOVER broadcasts ....

    This means to me that pfSEnse does what it should do when it concerns DHCP.

    This doesn't mean that my iDevice couldn't continue using "192.168.1.29" and thus he has access to the network, and while doing so, he (iDevice) could create a huge IP network conflict - the IP "192.168.1.29" could already be assigned to another device.

    I guess the question isn't DHCP-server related.
    For some more solid security, paulanand should work with IP+MAC firewall rules to begin with (and understand that these can be spoofed).
    The only real security here is some higher level authentication system.

    edit: as always : all pfSEnse versions are broken, except the last one - 2.2.2 ;)
    edit2: I didn't test with "Static ARP entries" activated.


  • Banned

    Another day, another reason to avoid bitten fruit co. (TM) products.


  • Netgate

    Umm. No.

    Device is sending DHCPREQUEST. Proper response if the address is in use, on the wrong network, etc, is DHCPNAK.

    Device is then giving up and sending DHCPDISCOVER.  Proper response is DHCPOFFER.

    My first guess would be something wrong at layer 2.

    It's not "bitten fruit."



  • @Derelict:

    Umm. No.
    Device is sending DHCPREQUEST. Proper response if the address is in use, on the wrong network, etc, is DHCPNAK.

    Yep. Note the fact that pfSense isn't replying anything. No NACK, no GOWAY, nothing.

    @Derelict:

    Device is then giving up and sending DHCPDISCOVER.  Proper response is DHCPOFFER.

    DHCP server is running in "Deny unknown clients" mode, so it will not offer an IP to a MAC that is not on the list.
    Should it say: NACK, no GOWAY, something else ? nothing ?

    @Derelict:

    My first guess would be something wrong at layer 2.

    That's what made me thing.
    Static ARP enforcement somewhat make DHCP being dropped (when coming from pfSEnse - client DHCP logs are visible) ?
    Anyway, I didn't test with "Static ARP" activated.

    @Derelict:

    It's not "bitten fruit."

    I know.
    The "fruit" was just a device that I could use for testing.
    If there is a BYOD-issue, related to the Captive Portal, I see a 80 % chance that it concerns a Android device ;)

    Edit: to make doktornotor happy, I retested with a laptop (Dell is ok ?).
    The results were identical - but I know now that the Windows 8 OS on the laptop is a real potential DHCP-(sp/h)ammer.


  • Netgate

    If it's set to deny unknown clients I believe it doesn't respond at all but I'd have to test it to see.

    Double check the MAC address.  Packet sniff at the pfSense interface on which the DHCP server is running.



  • Sorry for my misinterpretation. I don't use pfsense as that kind of security layer.

    I just expected that once I have deleted a machine from the static mapping, pfsense will not entertain that machine at all.

    The fact that it says "Deny unknown clients" gives me that thinking that it will only give out IPs to mapped machines.

    @Derelict:

    Is the static mapping inside your DHCP pool?

    ISC DHCP is pretty good about assigning the same IP address to the same MAC address until some other MAC address has been assigned the same IP.  The dormant assignment history can stick around for a long time if you don't have enough unique MAC addresses requesting IPs so the pool wraps.

    Correct me if I am wrong:
    If I have deleted a static mapping for host1, mapped host2 to that previously used IP, host1 will not be getting an IP.



  • @Paul:

    Sorry for my misinterpretation. I don't use pfsense as that kind of security layer.

    Ok for me ;) The discussion is about the DHCP server (ISC DHCP - what it does, or should do).

    @Paul:

    I just expected that once I have deleted a machine from the static mapping, pfsense will not entertain that machine at all.

    Replace epfsense by "the ISC DHCP server on pfSense" and you're good.

    If a client assigns itself a static IP witht he right mask and gateway, pfSense will route it just fine. Other tools like a firewall etc should be used to change that.

    @Paul:

    The fact that it says "Deny unknown clients" gives me that thinking that it will only give out IPs to mapped machines.

    That's what I showed some messages earlier in this thread.

    @Paul:

    Correct me if I am wrong:
    If I have deleted a static mapping for host1, mapped host2 to that previously used IP, host1 will not be getting an IP.

    In this case (when  checked "Deny unknown clients") 'pfSense' (the DHCP server ;)) will not reply that that client's DHCP request.



  • Okay Gertjan understood. How do I close this thread?



  • You don't  ;)

    A forum admin can do so, if things go nasty, but that is rare.

    "Closing threads" isn't really needed anyway.