vlan stopped handing out IP addresses

WSM-12.9.3 / FSM-12.8.2
Firebox M370

After losing power to our facility during a storm, 8+ hours, the next day we had 6 IP phones not registering with our onsite server. As it turned out those 6 phones were not receiving an IP address from my Phone VLAN. My Firebox is handling the dhcp of my vlan.
My Phone VLAN has an address pool of .100-.199, with approx. 65 phones in use. All the phones have a PC attached and all Pc's had internet access while the phones weren't working, so my network was working.

What I found was the VLAN was handing out the last of the IP's, in the upper range, .150 through .199. The IP's below .150 were random and not all being used.

As a test I added to my address pool, I extended to .210. That's when 5 of my 6 phones received an IP address, .200 and above. Currently .200-205, 207,208 are being used.

I cleared my Arp cache and rebooted my firebox but that didn't seem to help.

My firebox reboots every morning @ 4am and my phone server(3cx) reprovisions every night.

Question: what would cause the phones or vlan not to use the lower IP's in the pool first, then act as if I ran out of IP's?



  • Options

    No idea - quite odd.
    A reboot of the firewall will clear the DHCP list and the ARP cache.
    You can turn on Diagnostic logging on DHCP Server. Perhaps that will show something to help understand this.

    Consider opening a support case on this.

    Just curious, why is FSM at a lower version than WSM, since FSM is part of WSM

  • Options
    edited June 27

    Thanks Bruce,
    I opened a case with WG, I'll update when we have an answer.

    I also bumped up my DHCP diagnostic logs to med.

    Probably with the idea I was going to be upgrading, higher version of WSM when upgrading FSM and now I'm way behind.
    Next on my list, update my Firebox!!

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @bford
    There's a few things that could be causing the scope to start at the back end like that.

    -Some clients will use DHCPINFORM to get a preferred IP address. If you've ever noticed a workstation sticking to a specific IP address via DHCP even if there isn't a DHCP reservation for it, it's probably this.

    -There may be a lot of DHCPNAK activity, or other random MAC addressed that have fallen off the ARP table, but still have DHCP reservations. (By default DHCP leases are for 8 hours, even if they're only used for a few seconds.)

    -There might be an issue with the DHCP server on the firewall.

    If you're seeing any logs related to the DHCP server on that network that might suggest a problem, please copy them into the case -- it'll help the technician that's assigned to the case identify the issue.

    -James Carson
    WatchGuard Customer Support

  • Options

    @Bruce_Briggs and @james.carson

    I did open a case with Watchguard; #02078563, which has been closed.
    Worked mostly with Ryan in trying different things, he had me looking over my network for potential problems. I could not find anything new or any changes that might have occurred due to the power outage.

    We didn't come up with any specific cause to our problem or any specific fix.

    After several days of poking around and not finding anything specific, along with the phones working OK I decided to try to revert my changes I made to get the 6+ phone to work.

    I removed my extended DHCP IP pool .100 - .210 back down to my original pool of .100 - .199.
    I then rebooted each phone that had a .20x IP. Fortunately, and partially to my surprise they all got a lower IP address.

    Part of my frustration or lack of knowledge, is they still grabbed the higher end IP addresses while leaving multiple lower IP's unused.

    This is the order in which I rebooted the phones.
    Phone 1- ip .208 went to .196 (ip's .151 - .195, .197-199 utilized)
    Phone 2- ip .207 went to .138
    Phone 3- ip .204 went to .139 (.137-.150, open)
    Phone 4- ip .202 went to .140
    Phone 5- ip .203 went to .141
    Phone 6- ip .200 went to .142
    Phone 7- ip .201 went to .143
    Phone 8- ip .205 went to .144

    IP's 103, 107-109, 111, 112, 114, 117-136, .145-.150 open
    IP's .151 -.199 used

    This comment from Ryan did make me wonder if he thoroughly understood my problem.

    "The location of the IP that is handed out from within the scope set for the DHCP server does not indicate anything about the state of the DHCP server. IPs will be shuffled around all the time and the issue only comes into play if we are exhausting addresses without having more clients than there are addresses. If anything, I suggest reducing the DHCP scope to a value closer to the expected host count."

  • Options

    If I understand your configuration, your IP phone is acting as a switch for your PC.
    Are the phones and the PC's on the same subnet, or are the phones on a different VLAN than the PC's?
    If it's the second option I would look at the IP phones themselves and not the firewall.

    Having your phones re-provision on a 3CX system every night isn't necessary as sometimes the phones don't take the provisioning and revert to default.
    This comes from over a dozen years of experience running an on prem 3CX system myself.

    Between the firewall reboot every night (why???) and the 3CX reboot every night (again, why???) it doesn't surprise me you are having this issue.

    If a service on the 3CX needs restarted every night just create a script on the server to restart that service when you want. I have one running twice daily for a very specific purpose.

    I think it's a 3CX and phone issue, not a firewall issue.


    • Doug

    It's usually something simple.

Sign In to comment.