Not getting an Ipv6 IP

[depeo]

Hi,

I have an issue on all my clients (a Macbook Pro and a HP laptop with Fedora Linux), I don't get a ipv6 address unless I restart radvd in the opnsense interface.

Wifi or wired doesn't matter.

I have tried both managed(dhcpv6) and unmanaged, same problem.
If I reboot the client computer, I have to restart radvd in opnsense again to get a ipv6 ip.

Opnsense is running ion bare metal with a intel x710 nic(latest firmware)
I'm using the standard settings in radvd.

I have a public /64 assigned to the interface/vlan.
Any idea what I can do to solve it? It's super annoying.

[seacycle]

Does a rebooted client never get an address, or does it get one if you wait long enough for radvd to send out an unsolicited router advertisement? Between 200 and 600 seconds may be the default configuration, but you can adjust it way down experimentally adjusted down for testing. Restarting radvd will send one out immediately.

If it never gets an address, maybe radvd is falling over somehow.  If it does get one within 600 seconds, I would be suspicious that something is blocking the router solicitation messages from the client getting to the router.  A tcpdump to capture router advertisements (icmp6 134) and router solicitations (icmp6 133) done both on the client and on the router should clarify what is going on.

Just testing on a macos client, capturing both (adjust for whatever network interface is relevant on your client):

Code: [Select]

sudo tcpdump -vvv -ttt -i en0 icmp6 and \( 'ip6[40] = 133' or 'ip6[40] = 134' \)
And unplug and re-plug the ethernet cable and I see the solicitation and immediate response:

Code: [Select]

tcpdump: listening on en0, link-type EN10MB (Ethernet), snapshot length 524288 bytes
 00:00:00.000000 IP6 (flowlabel 0xd0000, hlim 255, next-header ICMPv6 (58) payload length: 8) flux.local > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8
 00:00:00.008806 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 144) fe80::2e2:69ff:fe53:c44e > flux.local: [icmp6 sum ok] ICMP6, router advertisement, length 144

If you see the solicitation, but no advertisement in response, then run a similar tcpdump on the router side and see if the solicitation makes it there. If it doesn't, then something in between ate it, and that is your problem.  If the solicitation does show up on the router, but it doesn't send a response out, something is likely up with radvd.

Since you say that client get an address on restarting radvd, I believe that shows that the router advertisements can get from the router to the client, so that is unlikely to be the problem.

In my case, I once had a buggy firmware revision on a wifi access point that was dropping router solicitations, causing client to not get an address until the unsolicited advertisement rolled around up to 10 minutes later.  If not a bug like that blocked router solicitation, an intermediate switch with inappropriate ACLs on it, or some firewall rule on either the client or the router could be blocking the necessary icmp6 messages.

[depeo]

Thanks for the reply.

I will try tcpdump.

I'm wondering if my switch is blocking the ra packages somehow, A while ago I tried to block my Apple TV from sending bogus ipv6 addresses to the whole network. Apparently it does this due to something called Thread.

But If the switch was the issue, I don't think a restart of radvd would solve the problem.

[seacycle]

The router advertisements from your Apple TV are not bogus, but they may also not be at all useful if you have no thread devices you want to communicate with. (The Apple TV acts as a border router for a network of thread devices. Thread is all IPv6. If you have no thread devices, you don't need a border router, but in typical Apple fashion, there are no knobs to turn it off on the Apple TV device itself. Thread capable HomePods do the same thing.)

I'd suggest disabling whatever you did to block the router advertisements from the Apple TV and see if that resolves the problem. Unplug the Apple TV from the network for the experiment if you don't want it involved while the defenses are disabled. If that fixes it, then the block you applied may be too broad in scope.

[mooh]

I agree with seacycle. It's best not to explicitly block IPv6 to avoid Thread traffic. In my home network, I have created a dedicated home automation VLAN and all the home automation stuff is on it and separated from the rest. I have set up a mDNS server and firewall rules to allow my personal devices on my private VLAN to talk to the home automation stuff.

[depeo]

I solved it, I rebooted the switch and everything magically started working.