DHCP Lease Times for Static IP Addresses

i would try to test the "Netgear router in AP mode" to check if the problems comes from sophos or netgear.

i use XG with Sophos AP and DHCP without any problem.

If you connect a mobile device or notebook within this WLAN ... the problem exist too? Possible to capture the DHCP traffic?

I only have issues with these particular devices.  Laptop, phone, media streaming devices, etc. all have no issue with this network segment.  If I use a different AP, the issue goes away, but I do not want to keep the old hardware on my network.  I don't think the problem is JUST the AP's, as there are a few of the devices that connect and reconnect without issue.

Do you know of a way to make the static lease never expire?

It appears that the max lease time in the XG is 30 days.

I don't think any of the settings you changed on the new APs should make a difference. Are there any other security settings on the APs that would keep a device from changing its IP or block certain packets? Do the APs have an internal DHCP server that's configured strangely and not completely offline?

You can try capturing packets on the XG from one of the devices and look for the difference between what it sends on a power cycle and what it sends when the lease expires. That might provide a clue.

Can you tell when the light goes offline? Is it at half of the lease length, 90% of the lease length, or 100% of the lease length? I just know what I read online about this process, but according to what I read, at 50% of the lease time the device reaches out to the DHCP server from whence it got its lease. If it goes to 90%, it will generate a broadcast -- as it does when it powers up -- asking for any DHCP server to respond. So my guess is that something is going wrong with the renewal (aT 50%) that's locking up the lights (which don't see or don't understand the reply) and they don't go on to do the broadcast request. So you power cycle them and they do.

My guess would be the AP is somehow not passing the XG's renewal message through, maybe due to a security setting in the AP to stop unsolicited "renewals" from changing IP addresses.

I didn't think it had anything to do with AP settings, but low hanging fruit....

There really aren't any security settings other than the authentication method. There is no DHCP on the AP's either, so no dice There.

I'm not sure how to capture packets - if you could provide instruction or point me to a document or something that would be great. 

It appears as though it is employing the 50% rule.  Maybe the XG is blocking broadcasts?  I see in the logs all the time denied traffic that is going to xx.xx.xx.255 - is that a broadcast?  How do I create a rule to allow that?  I think you may be on to something with that thought. As soon as I'm back in my office I'm going to chase that line of reasoning. 

Yes .255 is broadcast. But it's backwards from your problem, which is that DHCP works when the device initially broadcasts its request, but it doesn't work when it goes directly to the DHCP server itself to renew the lease. It could be that the device is doing things in a slightly strange way that the XG doesn't quite like, I guess, too.

In the GUI, under Diagnostics, there is a Packet Capture. You specify what Packets to capture with a BPF-language filter, In your case, I think you need one like ether host aa:bb:cc:dd:ee:ff where aa:bb:cc:dd:ee:ff is the MAC address of one of your problematic devices. Let it run for the full cycle -- there shouldn't be much traffic, and you might need to use the Refresh button to update the display so you see it. When you've gone through the entire cycle from before power-up to after it's offline, you can stop the capture and look at what packets you got, and hence get an idea of what the device was asking and what it should have received back.

Is it also possible to put the Netgear router-as-AP back into the mix just to test this and eliminate it as an AP-related issue?

OK, so I got the packet capture going and there is a ton of communication for such a simple device.  After just a few minutes, I have 8 pages of information.  The only thing I found that was interesting was this:

Do you have any idea what this means?  I will let it keep running until it loses connection and start analyzing the information.

I can put the other AP back into the mix, but I have it performing other duties and it will take a while to reset it and get it reconfigured for this purpose.

Good catch. Port 67 is a BOOTP port and also DHCP so perhaps that is the issue. If the 10.30.20.35 is the IP address of your device, it does look like it's attempting to do something DHCP-related directly to the server. (I assume that 20.30.20.1 is the firewall's IP on that subnet, and hence is the DHCP server.)

So it looks like there was a violation that I'm guessing is the reason things are failing as they are. Not sure what the Local Access Control List is, exactly, but it's evidently not allowing some devices (or a subnet) to talk to port 67. And that would fit your symptoms: power-on is a broadcast which doesn't violate the ACL, but renewal is a direct connection which does.

Hi,

have you created list of devices that use the ACL control access on your network?

I have one devcvie  on my network (IoT) that has a static address that is renews every 5 minutes when it connects and performs updates. I do see a lot of port 66/67 errors as well as successful renews. I did create  thread on the subject but never received any what I would call meaningful answers, so I left the device as is because it is working correctly.

Ian

You are correct on your assumptions.  10.30.20.35 is the device and 10.30.20.1 is the DHCP on the firewall.

In case you have not been able to glean from all my questions, I am not a firewall expert so I have not gotten very far in creating rules.  I have essentially gotten to the point that I have internet access for everything and that's about it.  I was wanting to just get everything working and then start fiddling with rules once I had the time.  I don't even know what the ACL is, so if there is one, it is not intentional and I did not put anything into it.

I will keep chasing this train of thought and see what I find.

Thanks for getting me pointed in the right direction.  Interestingly, the device that I am following has yet to fall off the network.  Previously it had only taken a few minutes, but we're over an hour here and it is still connected.  

I seem to always get the weird ones.

I have not created an ACL (that I know of at any rate).  Can you link to your thread just for fun?