IPv6, Track interface, stale DHCPv6 leases and VLAN prefixes

[Linwood]

I have a self inflicted problem I cannot seem to resolve.  Or it may have timed out now, but not sure.

OPNSense 22.7.10 on Comcast, /60 prefix delegation.

I originally set up multiple VLAN's with different prefix ID's, and for reasons unrelated (and probably wrong) I then changed some.  So my LAN ID went from 1 to 0, and at present I have no other VLAN's set up for ipv6.

I am using track interface (WAN), and not setting any specific DHCPv6 attributes, the DHCPv6 relay is not enabled. The LAN interface gets a proper address and is pingable from outside.   The WAN interface is set to DHCPv6, hint 60, ipv4 connectivity not checked, VLAN priority not checked.

A linux box on the VLAN  is getting a correct address of 2601:xxx:xxxx:be60::11e9/128.  Note the "be60" the 0 is the prefix ID.  All good.

However, that linux box ALSO is getting an address with "be61", from (I assume) the period when I had the prefix ID = 1 on LAN.

It seems to come and go every few hours.  When it gets the "be61" address it stops working properly, as it's being used as a source address and it is no longer routable.  If I delete that address (ip -6 addr del) that linux box works again, all good.  In an hour or three it comes back.

The Services / DHCPv6 / Leases shows the bad address, but there's no delete option.  If I restart that service it vanishes from the screen, but again comes back later.  If I enable configuration of DHCPv6 options on LAN I see no place to configure leases either (I then put it back unchanged).  Browsing around in /etc doesn't show any config or leases file.

I'm hoping if I just let things sit for a day it will go away (it may have actually done so, it's now been 4 hours). But what I would like to understand is where these reside, and how I can delete/remove/change them if this happens again.

How do you delete a bad lease with the wrong prefix ID so they don't come back?

Here's the log from the linux box showing activity over night if it is helpful.  Notice the be61's coming back.  Note  I had other systems also screwed up by this one was easiest to debug (and also an NMS system so it immediate threw alarms when it got the bad address).

Linwood

Code: [Select]

Jan  2 00:37:08 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 01:35:34 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 02:33:02 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 02:33:02 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be60::11e9 on eth0.*.
Jan  2 02:33:02 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 02:37:33 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 03:27:58 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 03:27:58 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 04:27:11 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 04:27:11 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 04:29:57 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be60::11e9 on eth0.
Jan  2 05:21:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 05:21:55 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be60::11e9 on eth0.*.
Jan  2 05:21:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 05:29:10 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 06:18:23 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 06:18:23 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 07:16:16 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 07:20:21 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.
Jan  2 08:14:08 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 09:13:52 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200


[Linwood]

Well, another 4 ours later or so, the bad address came back.  I really have no idea where it is coming from:

Code: [Select]

Jan  2 11:09:50 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 12:04:36 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:01:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200



[Linwood]

And just like that an hour later it removed the bad address.   I'm not making any configuration changes anywhere in these times, it just comes and goes and goes and comes.

Code: [Select]

Jan  2 13:01:55 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be61::2000/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms avahi-daemon[765]: Registering new address record for 2601:xxx:xxxx:be61::2000 on eth0.*.
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 13:57:42 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 14:57:20 nms systemd-networkd[741]: eth0: DHCPv6 address 2601:xxx:xxxx:be60::11e9/128 timeout preferred 3718 valid 7200
Jan  2 14:59:40 nms avahi-daemon[765]: Withdrawing address record for 2601:xxx:xxxx:be61::2000 on eth0.


[KHE]

Hi,

the way I removed such unwanted addresses on a Linux client, was to edit the /var/lib/dhcp/dhclient6.<ifname>.conf and remove the address there. I stopped the dhclient6 process before. After a restart (ifup) of the dhclient6, the old address was gone.

KH

[Linwood]

I can't find anything that looks like that, did a "find / -name dh*6*".  Running ubuntu 20.04.5.

I think systemd-networkd is doing it there, but /run/systemd/netif/leases is empty as well (though ../links has the interace information such as DNS server from DHCP).   I found notes saying they should be in the leases folder, but it's empty.

That's also consistent with netplan's answer:

netplan ip leases eth0
No lease found for interface 'eth0': [Errno 2] No such file or directory: '/run/systemd/netif/leases/2'


I can't recall if I have rebooted that server, trying that now in case the leases are more ephemeral.

I'm thinking if that doesn't do it, I need to sniff and see for sure that the linux dhcp6 client is requesting the address and that OPNsense is granting it, as opposed to Linux just perpetuating it on its own.

[Linwood]

OK, this is definitely OPNsense's fault.

I set up a capture and just left it running until I got another renewal of the bogus address.



This is a somewhat redacted form, but you can see the linux box doing a renewal request, followed by OPNsense responding.  The renewal request has the correct address with "be60" but the response has BOTH the correct "be60" but also contains the incorrect "be61" that does not have the right VLAN prefix (in fact be61 is no longer valid for any interface, and it should know that).

Yet that address is not on the dhcp6 leases page anywhere, and in browsing around on disk I have yet to find it either.

How can I clean OPNsense of a bad lease that it keeps forcing back on the client?