DHCP - Why Am I Seeing This?

[spetrillo]

I am looking at the DHCP server log and seeing alot over and over of these:

2020-07-20T14:09:56   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:56   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:55   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:55   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:54   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:54   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:53   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:53   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:52   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:52   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:51   dhcpd: DHCPOFFER on 192.168.0.11 to c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1
2020-07-20T14:09:51   dhcpd: DHCPDISCOVER from c4:ad:34:b6:ae:75 (MCSW_1) via lagg0_vlan1

What is wrong here? I am not seeing this IP show up in the leases section.

Steve

[wizziLalev]

Hi,
May I assume that 192.168.0.11 is your OPNSense box and c4:ad:34:b6:ae:75 is a client inside your LAN? If yes, I'm seeing the same issue, all DHCP leases are being renewed wayyy too often and that cause some of my IOT devices to go crazy.

Not only that but laptops/phones at home which are using the same DHCP pool are affected also and their connection drop all the time for few seconds until their IP is being renewed.

Worst thing is I didn't change anything, currently running latest version of OPNSense and updating to it was last change in like 2 weeks.

[gpb]

Do you have a rule set up that's blocking the host from receiving the DHCP OFFER reply?  Not sure how that could be...but that looks strange for sure.  I fired up a phone that had been turned off for a while and I get one DISCOVER and OFFER (some additional ipv6 requests and offers) and then it goes silent.  I have my lease set to 28800 seconds though the messages state they are valid for 7200 seconds...so 1/4 the spec'd time.

[wizziLalev]

Yes it is strange and started from nowhere. I'm attaching logs and screenshots of DHCP config. All other configs are 100% default, no customizations etc. - using that box more as router than as FW.

---> logs <---
---> config <---

Will be grateful if someone give me idea what is going on, most of the portable devices are using WiFi at home and WAF just dropped a lot.

Best,

[gpb]

FYI...The files you posted are not public, can't view.

[wizziLalev]

Sorry, my bad, all links are updated

[gpb]

First not an expert.  It looks like the hosts are broadcasting (255.255.255.255) for some reason.  Is that host going offline intermittently (i.e., weak wifi signal)?  Seems unlikely across multiple devices...are they all the same type?  Or could there be a rule that is blocking them from something they want but can't get to and then they "panic" on error and broadcasts again where the DHCP server then acknowledges (lazy coding maybe...if fail re-establish/verify connection, for example).  You can see in some of the message the host is requesting too frequently, it doesn't look like it's an issue with OPNsense (aside from possibly a rule).  These looks like smart plugs or some IoT device...firmware updates?  Just thinking out-loud.

Jul 20 23:12:56 fw dhcpd: reuse_lease: lease age 415 (secs) under 25% threshold, reply with unaltered, existing lease for 10.10.100.124
Jul 20 23:12:56 fw dhcpd: DHCPDISCOVER from d8:f1:5b:83:f8:ee (ESP_83F8EE) via igb1
Jul 20 23:12:56 fw dhcpd: DHCPOFFER on 10.10.100.124 to d8:f1:5b:83:f8:ee (ESP_83F8EE) via igb1
Jul 20 23:12:57 fw dhcpd: reuse_lease: lease age 416 (secs) under 25% threshold, reply with unaltered, existing lease for 10.10.100.124
Jul 20 23:12:57 fw dhcpd: DHCPREQUEST for 10.10.100.124 (10.10.100.1) from d8:f1:5b:83:f8:ee (ESP_83F8EE) via igb1
Jul 20 23:12:57 fw dhcpd: DHCPACK on 10.10.100.124 to d8:f1:5b:83:f8:ee (ESP_83F8EE) via igb1

I have a bunch of smart plugs (ESP_* nomenclature which apparently refers to the wifi chip embedded) but not seeing anything like this.  Your config looks good...no different than mine...except I don't have the UTC/local time option selected.

Can you log additional traffic from one of these devices...PCAP...?  Might yield some additional info.

[Bonkerton]

According to
https://maclookup.app/macaddress/C4AD34

the MAC address belongs to a MikroTik device.
Does that get you further?

Also, if I'm remembering an old problem of mine correctly,
I had a static lease set (in OPNsense) for one of my phones on the main WiFi network,
and then for testing purposes wanted it to connect to another wireless SSID on a different VLAN.
I believe to remember that that caused problems with DHCP as well until I realized and disabled the static lease for the main LAN.

[spetrillo]

According to
https://maclookup.app/macaddress/C4AD34

the MAC address belongs to a MikroTik device.
Does that get you further?

Also, if I'm remembering an old problem of mine correctly,
I had a static lease set (in OPNsense) for one of my phones on the main WiFi network,
and then for testing purposes wanted it to connect to another wireless SSID on a different VLAN.
I believe to remember that that caused problems with DHCP as well until I realized and disabled the static lease for the main LAN.

Yes that is my edge switch...the problem is I am seeing more and more devices going thru this. I do not understand why there is no DHCPACK. The devices obviously can get the OPNsense DHCP server but it seems the ack never happens. I too am wondering if some addresses are being held. Is there a way to clear the DHCP server? Do I need to disable each DHCP scope and then reboot?

[spetrillo]

So I got some more info when I stopped the affected scope:

2020-07-21T20:15:16   dhcpd: lease 192.168.0.23: no subnet.
2020-07-21T20:15:16   dhcpd: lease 192.168.0.22: no subnet.
2020-07-21T20:15:16   dhcpd: lease 192.168.0.24: no subnet.

Why would I see this in the log?

[spetrillo]

This is definitely happening more and more often for me. Even when I get a DHCPACK the device seems to be lost and I cannot ping it any longer. This is beginning to be very frustrating.

Attached please find a representation of my home network. In this post I will focus on two issues. You will notice I have an AP and NAS attached to an edge L2 switch. The AP is on VLAN 1 and the NAS is on VLAN 20. I got the NAS on VLAN 20 last night and got it connected properly. When I came back this evening I can no longer ping the NAS, even though it is powered on and connected to the switch. I have a static IP of 192.168.20.2 assigned. THE AP example is a little different, in that it is not the AP having issues, but when I try to connect a wireless device to this AP's SSID I never get a DHCP ack:

2020-07-22T19:56:42   dhcpd: DHCPOFFER on 192.168.10.13 to c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10
2020-07-22T19:56:42   dhcpd: DHCPDISCOVER from c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10
2020-07-22T19:56:34   dhcpd: DHCPOFFER on 192.168.10.13 to c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10
2020-07-22T19:56:34   dhcpd: DHCPDISCOVER from c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10
2020-07-22T19:56:30   dhcpd: DHCPOFFER on 192.168.10.13 to c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10
2020-07-22T19:56:30   dhcpd: DHCPDISCOVER from c8:f3:19:4a:4b:93 (V60-ThinQ-5G) via lagg0_vlan10

As mentioned this is happening more and more often to me. I reset a device and get it working and then another one pops up. In fact I am now showing another smart power strip not being able to get DHCP IP, in the same fashion as the wireless device above. Lots of discovers and offers but no ack. Has anyone seen this and am I doing something wrong? Happy to provide whatever info needed. I am running 20.1.8.1 on the firewall.

Thanks,
Steve

[opns_neuling]

status now?

[spetrillo]

Its better since I upgraded to 20.7. I still have a few that do this but much better.