This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dhcp server giving out ip adresses to non existing devices

Esterday before the latest update I got an Alarm from my UTM Home Edition, that I exceeded the number of ip addresses in my license by about 500 addresses. This happens to my DMZ network and the guest WLAN. Looking at the reports there are no security breaches (as I can tell). Also there are no Mac addresses in the lists.
I then reduced the the DHCP ranges for both networks to a maximum of five addresses each. No luck. The list for the licensing ips still tells me all kinds of addresses outside the defined ranges.
Where do all the requests for IP addresses come from?

Any ideas?

Thanks


This thread was automatically locked due to age.
  • Have you looked in the DHCP logs?  I'll wager that they're not actually machines on your network.  I recall I had a similar problem a couple of years ago where for some reason my UTM was somehow counting addresses that weren't even on my LAN.  I don't recall the specifics or the resolution, but I'll try to find the old thread...
  • Thanks for your answer, unfortunately the link from BarryG doesn't work any more.
    It seems to me that one of my internal desktops is causing this problem. I get the message from the UTM every day at 6:40pm CET. 
    There are tons of messages send to all kinds of ip addresses. I shutdown the desktop and will try to find out what happens.
  • I have found the cause. I had the network documentation software "The Dude" installed on one of my PC's. Scanning the network suddenly shows all kind of not existing devices, with the IP addresses the UTM tells me are outside the license range.
    This sure is strange. The UTM lists devices in the license area, that don't exist, just because a network scan was running.
  • Whenever a packet transits the UTM, its internal IP is counted.

    Cheers - Bob
  • Hi,

    Are you running the http proxy aka Web Protection?

    If not, this shouldn't happen as it has been reported and fixed before.

    If so, I'm not sure there's a good fix.

    Barry
  • Hi Bob,

    He's saying non-existent devices are getting counted due to his network scanner which is scanning the whole networks.

    I've seen reports before of this happening if the proxy is running.

    I've seen it happen without the proxy, with nmap scans of my DMZ from my LAN, but that was long ago and was fixed by Astaro.

    Barry
  • Thanks for your answers. What is strange is that only addresses from the Guest wireless LAN and from the DMZ are given away. No internal addresses are effected. I keep getting the warnings abour exceeding IP's at 6:40pm an 6:40am. Have a look at the DHCP Logfile
    18:40 equals to 6:40pm

    2014:02:18-18:39:49 myutm dhcpd: uid lease ***.***.***.100 for client 00:04:20:2b:1b:35 is duplicate on ***.***.***.0/24
    
    2014:02:18-18:39:49 myutm dhcpd: DHCPREQUEST for ***.***.***.61 from 00:04:20:2b:1b:35 via eth0
    2014:02:18-18:39:49 myutm dhcpd: DHCPACK on ***.***.***.61 to 00:04:20:2b:1b:35 via eth0
    2014:02:18-18:40:21 myutm dhcpd: DHCPREQUEST for ***.***.***.74 from f4:1b:a1:e7:10:72 via eth0
    2014:02:18-18:40:21 myutm dhcpd: DHCPACK on ***.***.***.74 to f4:1b:a1:e7:10:72 via eth0
    2014:02:18-18:41:14 myutm dhcpd: DHCPREQUEST for ***.***.***.52 from 00:0c:29:c0:0e:55 via eth0
    2014:02:18-18:41:14 myutm dhcpd: DHCPACK on ***.***.***.52 to 00:0c:29:c0:0e:55 via eth0
    2014:02:18-18:41:52 myutm dhcpd: DHCPREQUEST for ***.***.***.71 from dc:9b:9c:c8:01:9f via eth0
    2014:02:18-18:41:52 myutm dhcpd: DHCPACK on ***.***.***.71 to dc:9b:9c:c8:01:9f via eth0
    2014:02:18-18:42:06 myutm dhcpd: DHCPDISCOVER from 08:60:6e:ec:e9:1d via eth0
    2014:02:18-18:42:06 myutm dhcpd: DHCPOFFER on ***.***.***.40 to 08:60:6e:ec:e9:1d via eth0
    2014:02:18-18:42:06 myutm dhcpd: DHCPREQUEST for ***.***.***.40 (***.***.***.1) from 08:60:6e:ec:e9:1d via eth0
    2014:02:18-18:42:06 myutm dhcpd: DHCPACK on ***.***.***.40 to 08:60:6e:ec:e9:1d via eth0
    2014:02:18-18:43:17 myutm dhcpd: DHCPREQUEST for ***.***.***.5 from 00:1a:8c:2c:57:78 via eth0
    2014:02:18-18:43:17 myutm dhcpd: DHCPACK on ***.***.***.5 to 00:1a:8c:2c:57:78 via eth0
    2014:02:18-18:43:27 myutm dhcpd: DHCPREQUEST for ***.***.***.50 from 00:0c:29:17:ed:64 via eth0
    2014:02:18-18:43:27 myutm dhcpd: DHCPACK on ***.***.***.50 to 00:0c:29:17:ed:64 via eth0
    2014:02:18-18:43:56 myutm dhcpd: DHCPREQUEST for ***.***.***.71 from dc:9b:9c:c8:01:9f via eth0
    2014:02:18-18:43:56 myutm dhcpd: DHCPACK on ***.***.***.71 to dc:9b:9c:c8:01:9f via eth0
    2014:02:18-18:44:45 myutm dhcpd: DHCPREQUEST for ***.***.***.70 from 28:6a:ba:07:57:48 via eth0
    2014:02:18-18:44:45 myutm dhcpd: DHCPACK on ***.***.***.70 to 28:6a:ba:07:57:48 via eth0
    2014:02:18-18:44:50 myutm dhcpd: DHCPREQUEST for ***.***.***.73 from f4:1b:a1:22:91:ef via eth0
    2014:02:18-18:44:50 myutm dhcpd: DHCPACK on ***.***.***.73 to f4:1b:a1:22:91:ef via eth0
    2014:02:18-18:44:51 myutm dhcpd: uid lease ***.***.***.100 for client 00:04:20:2b:1b:35 is duplicate on ***.***.***.0/24
    2014:02:18-18:44:51 myutm dhcpd: DHCPREQUEST for ***.***.***.61 from 00:04:20:2b:1b:35 via eth0
    2014:02:18-18:44:51 myutm dhcpd: DHCPACK on ***.***.***.61 to 00:04:20:2b:1b:35 via eth0
    2014:02:18-18:45:25 myutm dhcpd: Internet Systems Consortium DHCP Server 4.1-ESV-R8
    2014:02:18-18:45:25 myutm dhcpd: Copyright 2004-2013 Internet Systems Consortium.
    2014:02:18-18:45:25 myutm dhcpd: All rights reserved.
    2014:02:18-18:45:25 myutm dhcpd: For info, please visit www.isc.org/.../
    2014:02:18-18:45:25 myutm dhcpd: WARNING: Host declarations are global.  They are not limited to the scope you declared them in.
    2014:02:18-18:45:25 myutm dhcpd: Internet Systems Consortium DHCP Server 4.1-ESV-R8
    2014:02:18-18:45:25 myutm dhcpd: Copyright 2004-2013 Internet Systems Consortium.
    2014:02:18-18:45:25 myutm dhcpd: All rights reserved.
    2014:02:18-18:45:25 myutm dhcpd: For info, please visit www.isc.org/.../
    2014:02:18-18:45:25 myutm dhcpd: Wrote 0 deleted host decls to leases file.
    2014:02:18-18:45:25 myutm dhcpd: Wrote 0 new dynamic host decls to leases file.
    2014:02:18-18:45:25 myutm dhcpd: Wrote 9 leases to leases file.
    2014:02:18-18:45:25 myutm dhcpd: Listening on LPF/eth0/00:0c:29:ba:f2:30/***.***.***.0/24
    2014:02:18-18:45:25 myutm dhcpd: Sending on   LPF/eth0/00:0c:29:ba:f2:30/***.***.***.0/24
    2014:02:18-18:45:25 myutm dhcpd: Sending on   Socket/fallback/fallback-net


    (I know that there is an error message about duplicate IP addresses. I just changed some devices around to be able to assign smaller ranges to DHCP to prevent the problem. In the IPv4 Lease table there are still a couple of leases present that seem to cause the duplicate error. But I couldn't find a way of getting rid of this.)

    There is nothing about these phantom leases. The DHCP Server of the DMZ was even switched off.

    Here is what I found in the system messages protocol
    2014:02:18-18:40:09 myutm adbs-maintenance[6696]: running count_active_ip.plx
    
    2014:02:18-18:40:09 myutm count_active_ip[6744]: count_active_ip: checking active IP addresses
    2014:02:18-18:40:09 myutm count_active_ip[6744]: Home use or NTT OEM license detected
    2014:02:18-18:40:09 myutm count_active_ip[6744]: Counted IP Addresses: v4: 342 / v6: 0
    2014:02:18-18:40:09 myutm count_active_ip[6744]: license usage exceeds 110%: licensed: 50 counted v4: 342 counted v6: 0 enforcement: yes
    2014:02:18-18:40:09 myutm count_active_ip[6744]: License usage: EXCEEDING 110% OF USER COUNT on Sophos UTM
    2014:02:18-18:40:09 myutm adbs-maintenance[6696]: finished ADBS maintenance run


    The proxy is running on the system, except for the https.

    Cheers

    Roger
  • Nothing is actually being "given away" - these addresses are not being leased out by your DHCP server, but are being counted as "active" by the UTM because your scanner tried to access them. The reason that it's only affecting addresses on your Guest and DMZ networks is because traffic destined for those addresses has to pass through the UTM's routing engine, while probes to other addresses on the same subnet as the probing machine does not go through the gateway and is thus not counted.

    I had a similar problem some time ago, where a bittorrent client on my network kept trying to establish connections to misconfigured BT peers that were advertising their internal IP addresses instead of their public address. Since many of these were behind domestic cosumer routers which used the 192.168.1.0/24 subnet by default, which was also the subnet that I had chosen for my Guest network, all those peer requests were dutifully being routed to my Guest network and counted as active clients by the UTM.

    In my case, I simply changed my Guest subnet to something that is not used by default by any consumer gear, and those peer requests no longer get any further than the UTM and are not counted as local clients.

    I do believe that it's wrong for the UTM to count protected clients in this way - IMHO it should only count clients that it receives traffic from, not also those (possibly non-existent) that it routes traffic to, but it is what it is. It does appear that ping traffic to nonexistent clients is not counted, so if there's some way that you can ping first, then only probe machines that respond, that could help.