Acquiring ipv6 address can take 5 to 10 minutes.

[staticznld]

Hi,

After installer 20.7 i see some issues regarding IPV6.
After a complete restart of a Windows 10 clients it takes up to 5 a 10 minutes to acquire an IPV6 address.
I am not using DHCPv6 only stateless address configuration.
When restarting the Radvd service in the opnsense interface the windows 10 client immediately picks up an address.



Anyone an idea?

[franco]

Hi,

Probably... https://github.com/opnsense/core/commit/20efa4f46c2

At least that settles "MinRtrAdvInterval / MaxRtrAdvInterval were set to very low values (3 / 10) for no apparent reason" from the commit message.

The default values (200 s / 600 s --- 3,3 minutes / 10 minutes) are sane in general as they do not stress mobile devices so much constantly waking them up to say nothing has changed.

It's possible to set these manually in manual mode (interface settings), but it may require some more tinkering on your part.


Cheers,
Franco

[staticznld]

Thanks for the info!
Tried setting it up as before and indeed immediately an ipv6 address!

Switched back to default though.

[franco]

Ok, so case closed?


Cheers,
Franco

[gpb]

@franco, I ran into this issue (or at least similar) this morning after a power outage (clean shutdown), and upon restart I had no ipv6.  This went on for a few hours as I tried to figure out what was going on.  From the firewall (ssh) I could ping example.com, but from clients I could not.  Using the opnsense gui under interface diagnostics ping, I could not ping using the LAN interface, but could from the wan.  Updated to 20.7.1, no difference. 

I saw your notes posted above and went to manual RA settings, enabled for LAN, and found the setting to be disabled.  Set it to Stateless and was able to connect.  This may have been a coincidence, I can't say.  I'd have to try to recreate this with another reboot followed by this exact change.  It seems to make sense clients maybe didn't have a valid ipv6 prefix/route to the LAN interface and running a tracert timed out (which works fine now).

Maybe this provides a clue to others reports.  Is "disabled" what should be seen on first opening the RA for LAN interface once customization is enabled?  Is that the default?  Thx.

[Maurice]

MinRtrAdvInterval / MaxRtrAdvInterval values only affect unsolicited RAs. When new clients connect to a network, they send Router Solicitations to which radvd should always respond immediately.

Maybe the Router Solicitations never reach OPNsense. Windows misconfiguration / rogue firewall on the Windows machine / switch or access point which doesn't always properly forward IPv6 multicasts?

Setting MinRtrAdvInterval / MaxRtrAdvInterval to very low values might mask such issues by constantly flooding the network with RAs. But I wouldn't consider that a solution.

Cheers

Maurice

[gpb]

Thanks for the clarification, so would the multicast RA be disabled normally?  I left defaults in place, only set it from disabled to stateless.  I don't have an explanation, could have been coincidence.  The problem affected several Rpi's and Windows PC...didn't check other devices.  Was strange I couldn't ping the LAN interface address which would normally work fine (obviously).  Checking the windows PC after an ipconfig release/renew I didn't have a unicast address, just link local.  Again thanks.

[Maurice]

@gpb, this was meant as a response to @staticznld's issue.

I don't think yours is related because this should work even with RAs disabled:

Using the opnsense gui under interface diagnostics ping, I could not ping using the LAN interface, but could from the wan.

Cheers

Maurice

[gpb]

@Maurice...thanks...still good clarification.   

[marjohn56]

Seeing similar issue this morning, cannot say if it was after I had just updated to 20.7.1 or not, but no devices are getting a route.. very odd. Will investigate further tomorrow as no time today.


*** update ***


Turns out it was my primary switch...

[gpb]

Doing a packet capture, it looks like the router solicitation for the host is never answered and ipv6 address determination is done only when a router advertisement to all hosts is received.  That means there's a variable time delay spanning seconds to minutes depending on the intervals of those RAs.

Testing is easy enough, using an ipad, disable wifi, start packet capture on opnsense, enable wifi, watch the ipad screen until the screen updates to show the ipv6 addresses appear, then stop capture.

I'll assume I'm the only one having this problem, what can I do to further debug this issue?  I'm also assuming this is why I couldn't get ANY ipv6 addresses yesterday until I enabled RAs in general...using @franco's instruction about setting manual override for RAs on the LAN interface.  What component is responsible for answering a router solicitation?  I'm assuming it's RADVD...and not dhcpv6 (which is disabled on that interface and was never an option until enabling RA customization). 

Any guidance is appreciated...thanks!

[Maurice]

Actually, I'm now observing this issues with 20.7.1, too: Like @gpb says, a packet capture shows OPNsense receiving Router Solicitations, but often not responding with Router Advertisements. This is intermittent. It sometimes works, but mostly doesn't. Unsolicited RAs don't seem to be affected and are still being sent.

I didn't observe this on older versions. @franco, any idea if there recently have been changes which might be related?

Cheers

Maurice

[marjohn56]

Actually, I'm now observing this issues with 20.7.1, too: Like @gpb says, a packet capture shows OPNsense receiving Router Solicitations, but often not responding with Router Advertisements. This is intermittent. It sometimes works, but mostly doesn't. Unsolicited RAs don't seem to be affected and are still being sent.

I didn't observe this on older versions. @franco, any idea if there recently have been changes which might be related?

Yup, same again this morning, so not my switch. Seeing the same issue as you on wireshark; the radvd.conf appears the same, at least there were no changes to the creation routines that I can see between 20.1 and 20.7.
I've also tried the radvd deamon from a 20.1 dev version and that makes no difference either.


*** UPDATE***


3 minutes later it's working again !

[staticznld]

While digging further i also see the same issue.

Router solicitations are sent from a client (VU+ linux stb) but not answered.
When OPNsense sents an Router advertisement the stb is picking up an address and is connected through IPV6.

The packet capture future with Wireshark is great to analyse the problem!

Edit:

When creating a firewall rule to allow icmp6 to any it looks like its working.
Nope not working

[Maurice]

When looking at the 20.7.1 changelog, the only thing that gets my attention is "src: assorted multicast group join/leave corrections". But I've not looked at the code yet.