Strange dhclient lease times!

[logan]

I'm running OPNsense 25.1.1-amd64 with a fresh install. Had this same problem on an older version--OPNsense 22 (tried updating it to 23 and then 24 previously, but had to revert to a snapshot and finally got around to a new install). This is running as a VM on Proxmox if that matters.

My old ISP rarely changed my address assigned by DHCP, but my new ISP seems to do it once a week or so. Every time the lease expires, I do not get a new address and the gateway is marked down.

I have been reading and it sounds like something similar is a known issue in both pfSense and OPNsense and people deal with it with scripts that reset the WAN interface and such. What's weird to me is the details on the lease as found in /var/db/dhclient.leases.vtnet1

Code Select Expand

lease {
  interface "vtnet1";
  fixed-address 100.117.19.212;
  next-server 100.117.19.213;
  option subnet-mask 255.255.255.248;
  option routers 100.117.19.213;
  option domain-name-servers 192.168.254.1;
  option host-name "wocket";
  option broadcast-address 100.117.19.215;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 100.117.19.213;
  option dhcp-renewal-time 38734;
  option dhcp-rebinding-time 71134;
  option option-125 0:0:d:e9:20:4:6:30:30:44:30:44:30:5:c:33:32:30:32:34:33:37:32:31:32:39:33:6:8:4d:43:37:30:31:30:43:41;
  renew 6 1970/1/3 07:47:48;
  rebind 6 1970/1/3 15:51:55;
  expire 6 1970/1/3 21:02:14;
}
lease {
  interface "vtnet1";
  fixed-address 100.117.117.32;
  next-server 100.117.117.33;
  option subnet-mask 255.255.255.192;
  option routers 100.117.117.33;
  option domain-name-servers 192.168.254.1;
  option host-name "wocket";
  option broadcast-address 100.117.117.63;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 100.117.117.33;
  option dhcp-renewal-time 43200;
  option dhcp-rebinding-time 75600;
  option option-125 0:0:d:e9:20:4:6:30:30:44:30:44:30:5:c:33:32:30:32:34:33:37:32:31:32:39:33:6:8:4d:43:37:30:31:30:43:41;
  renew 6 1970/1/3 14:12:38;
  rebind 6 1970/1/3 23:12:38;
  expire 0 1970/1/4 02:12:38;
}
Apparently there are two valid leases for the same WAN interface? What happened today, was the gateway went down, I renewed the IP from the web interface and clearly dhclient thinks that both are still valid.

What's even more bizarre is the dates for renew, rebind and expire are only a few days from epoch time. I have a valid time though and had a valid time when these leases were acquired! All the other logs show the correct date and time.

Code Select Expand

logan@wocket:/var/db # date
Fri Feb 21 06:59:15 UTC 2025

The Internet Systems Consortium DHCP client keeps a persistent database of leases that it has acquired that are still valid.

Does dhclient think that both of the leases are still valid because the date/time for expiry is long in the past? Some sort of bug? A misconfiguration?

Thanks in advance for any help you can offer!

[EricPerl]

I believe these timestamps are server originated.
Bogus times in DHCP leases are likely to complicate renewal...
I suspect the IP mentioned in the DHCP ACK is used regardless of time validity. But again, it would be difficult to trigger a renewal in the past...

[ZPrime]

I am seeing "weird" stuff in dhclient.leases for at least one of my WAN interfaces as well. It's AT&T Fiber, and I'm bypassing their "BGW" device so I'm getting DHCP directly from their network (there's no "IP Passthrough" happening here). I'm not on v25.x yet, either - this is on 24.7.12, so I don't think this is a recent change.

My leases file has 11 separate "lease { }" stanzas in it, each of them with different renew, rebind, and expire dates and times. My dates and times appear to be relatively correct, but it seems to have a bunch of leases expiring several cycles "in the future," which I don't understand.

For example, it's currently 18:53. I have leases with a renew at 18:56 (this makes sense), but then also 19:26, 19:56, 20:26, 20:56, 21:26, 21:56, etc, all the way up to 23:56. I don't get why I have "future" leases, since I didn't think DHCP worked that way? The lease time is 3600 seconds (1hr), and I know that default behavior is to renew at the midpoint... I just don't get why I have "lease { }" entries for leases that shouldn't have been issued yet.

I don't seem to have any actual problems here, FWIW, just mentioning what seemed like odd behavior in my leases DB file.

(I was just looking through the file because I wanted to know the lease time, because I want to change my WAN MAC and was wondering how long I'd be stuck without service, because AT&T gives each customer an IP that doesn't really change, and will just ignore requests until the previous lease expires.)

[EricPerl]

I'm afraid that the times in the leases files are not local time adjusted. It looks like there's an offset in the DHCPACK.
I assume the code handles it properly as everything seems to work.

[logan]

I believe these timestamps are server originated.
Bogus times in DHCP leases are likely to complicate renewal...
I suspect the IP mentioned in the DHCP ACK is used regardless of time validity. But again, it would be difficult to trigger a renewal in the past...

That makes sense! Thank you! I ended up using a script to test the connection and reset the interface when the lease expires. Internet goes down for five minutes, but so far nobody has noticed. Might write another one to get a new lease every night when nobody cares. Pretty hacky!

[Xiche]

Looks like dhclient was changed in upstream FreeBSD (and pulled into OPNsense) to use CLOCK_MONOTONIC for its concept of current time, which results in the offsets being relative to uptime of the system rather than the real time.  As a result, the timestamps for renew, rebind, and expire in the leases file end up being Unix epoch + system uptime + calculated offsets from the DHCPACK.  Beyond being a bit weird, it seems like this is also buggy across reboots where the "now" time will effectively move backwards...

Upstream commit: https://cgit.freebsd.org/src/commit/?id=d854b4b2aa2b8b60e7fbca07e9637d035318aad5

EDIT: Looks like this was already reported here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283256