Messages

Dynamic leases are now showing up for me too.  Awesome.

As far as the status goes - and let me preface this by saying this is a WAG (Wild-Ass Guess) - I think it might be an NDP thing.  If you run `ndp -a` you'll see a bunch of stale addresses.  Addresses seem to go stale pretty fast.  Cisco defines stale as: "Previously-known neighbor is no longer reachable. No action is taken to verify its reachability until traffic must be sent."

Once I ping the client from the firewall, the status changes to on-line, and `ndp -a` no longer shows stale.

About 60 seconds later, the address goes stale again.

Looking elsewhere, stale is defined as "Not up to date", not to be confused with INCOMPLETE or FAILED.

In Juniper (JunOS) you can modify the time when an address goes stale, I haven't found that option yet in FreeBSD.

These are just my observations, not my SWAG (scientific wild-ass guess) :)  Maybe the status column is reacting to STALE when it should be reacting to something else... I dunno.

Where can I check if it's SLAAC adresses?

Are your router advertisements set to "managed"? (Services -> Router Advertisements -> LAN)  Your devices won't try to talk to a DHCP server unless the M (managed) flag is set.

Is there any thoughts to change from assited to managed?


I changed to managed. I will give a look if it's do the changes...

No changes at first look. Also no addresses under DHCPv6 leases....

Take a look at this thread: https://forum.opnsense.org/index.php?topic=35135.0

There's currently a bug where dynamic leases aren't showing up in the GUI.  There's a patch available in that thread.  But yes, it should be set to managed if you want DHCP to work. 

Try restarting networking on the client (systemctl restart systemd-networkd) or just rebooting it.

Also, do you have a static IP assigned to the LAN interface?  I remember there being bugs in the past if you were using "track interface"

Edit: actually, assisted should work also.

SLAAC stands for stateless address auto configuration, meaning, your workstation assigns itself an IP address based on what it sees in the router advertisements.  It's kind of like a 169.254 address in ipv4.  These self-assigned addresses COULD be based on your MAC address, unless your client has security extensions enabled, in which case they won't be based off your MAC.

Maybe you'll see something interesting if you tail your dhcp logs: tail -f /var/log/dhcpd/latest.log

Edit #2: is there anything in your /var/dhcpd/var/db/dhcpd6.leases file?

Where can I check if it's SLAAC adresses?

Are your router advertisements set to "managed"? (Services -> Router Advertisements -> LAN)  Your devices won't try to talk to a DHCP server unless the M (managed) flag is set.

[ff:fe]

Screenshot is unreadable, but assuming you configured it correctly: Probably SLAAC addresses. Do they have this pattern?

2a02:XXX:a774:be33:123:45ff:fe67:89ab

... and by the way: 2a02:XXX:a774::2 to 2a02:XXX:a774::ffff requires a /48 (because the subnet ID is 0x0000). Do you have a /48?

Are you sure?  Let's uncompress the IP's then compare:

2a02:xxx:a774::2 = 2a02:xxx:a774:0000:0000:0000:0000:0002

2a02:xxx:a774::ffff = 2a02:xxx:a774:0000:0000:0000:0000:ffff

This range fits in a /64, and I'd argue a /112 too, if the range ended in ::fffe

I think you're confusing 2a02:xxx:a774::ffff with 2a02:xxx:a774:ffff:ffff:ffff:ffff:ffff

Thanks rsk this saved my ass.

If I went to Firewall -> Aliases -> Search for alias things looked fine
When I went to Firewall -> Diagnostics -> Aliases and selected the alias, it was empty.

I took your advice and did rm -f /var/db/aliastables/* && /usr/local/opnsense/scripts/filter/update_tables.py and now everything works again.  Firewall -> Diagnostics -> Aliases -> selected alias now shows what should be in the alias, which fwiw is an ipv6 /32 network alias.