IPv6 from Android devices still broken

[rmayr]

I am trying it with "sloppy" right now, but am not sure if the problem really is limited to only ICMP6. As before, It's (also) TCPv6 SYN packets that are sent (unicast) to the OPNsense LAN Ethernet MAC address with a target IPv6 address on the WAN side.

Same high-level behaviour still: After some time being connected on the WiFi, trying to reload https://test-ipv6.com simply times out with "No IPv6 address detected" and those TCP SYN packets never receiving a reply. I can see the SYN packets on the LAN side of OPNsense:

Code Select Expand

22:32:09.825963 fa:17:c7:f8:dd:85 > ca:00:00:00:64:01, ethertype IPv6 (0x86dd), length 94: <myprefix>:2d9:c3d6:1433:ee1.37430 > 2a01:7e03::f03c:94ff:fed0:11a6.443: Flags [S], seq 1969279674, win 65535, options [mss 1432,sackOK,TS val 2090357468 ecr 0,nop,wscale 8], length 0
22:32:10.379084 fa:17:c7:f8:dd:85 > ca:00:00:00:64:01, ethertype IPv6 (0x86dd), length 94: <myprefix>:2d9:c3d6:1433:ee1.22000 > 2a01:4f8:13b:1643::2.443: Flags [S], seq 1286341450, win 65535, options [mss 1432,sackOK,TS val 2535439579 ecr 0,nop,wscale 8], length 0


going out on WAN (pppoe0) and immediately being answered from the WAN side:

Code Select Expand

22:32:09.826029 AF IPv6 (28), length 84: <myprefix>:2d9:c3d6:1433:ee1.37430 > 2a01:7e03::f03c:94ff:fed0:11a6.443: Flags [S], seq 1969279674, win 65535, options [mss 1432,sackOK,TS val 2090357468 ecr 0,nop,wscale 8], length 0
22:32:09.996886 AF IPv6 (28), length 84: 2a01:7e03::f03c:94ff:fed0:11a6.443 > <myprefix>:2d9:c3d6:1433:ee1.37430: Flags [S.], seq 2081477611, ack 1969279675, win 58996, options [mss 8440,sackOK,TS val 3773941169 ecr 2090357468,nop,wscale 7], length 0
22:32:10.379114 AF IPv6 (28), length 84: <myprefix>:2d9:c3d6:1433:ee1.22000 > 2a01:4f8:13b:1643::2.443: Flags [S], seq 1286341450, win 65535, options [mss 1432,sackOK,TS val 2535439579 ecr 0,nop,wscale 8], length 0
22:32:10.398194 AF IPv6 (28), length 84: 2a01:4f8:13b:1643::2.443 > <myprefix>:2d9:c3d6:1433:ee1.22000: Flags [S.], seq 2319345901, ack 1286341451, win 65178, options [mss 1290,sackOK,TS val 782819494 ecr 2535404002,nop,wscale 7], length 0

But those replies never make it back to the LAN interface. A few seconds later, I get a block entry in the filter log, for a different packet than the one that was silently dropped, though:

Code Select Expand

WAN In 2026-03-22T22:32:44 TCP [2a01:4f8:13b:1643::2]:443 [<myprefix>:2d9:c3d6:1433:ee1]:52302 block Default deny / state violation rule

And that's what's really confusing me: None of that ever happens with other Linux clients on the same LAN, and if I reconnect the Android client to get a new SLAAC address, it immediately works again (for a short time). Which part of the pf state tracking logic goes out of whack here, and why only for Android clients?

[Javier®]

Hi everyone, I'm not sure if this will help with disconnections on Android devices, but it also happens with iOS devices. A post mentioned that the solution to the disconnections was to extend the lifetime.

Extend the default RDNSS advertisement lifetime to work around RDNSS expiry bug on macOS / iOS

https://blog.infected.systems/posts/2024-12-18-working-around-macos-and-ios-rdnss-expiry-bug/

[Patrick M. Hausen]

I'm a bit puzzled by this. Why does a device waking from sleep after hours or even days assume nothing changed and not immediately renegotiate just everything about its network environment? Even if it's wifi and the SSID is the same I could close the lid of my Macbook in our office in Karlsruhe and reopen it in our office in Frankfurt.

[nero355]

I'm a bit puzzled by this.

You are not the only one... LOL! :)

But there have been many topics about this lately and there seems to be something weird going on when the right "timing values" are not used.

Since I can't test it for now I will just keep reading as much as I can about it and hope things will get sorted by the time I get to use IPv6 here!

[Javier®]

This happens to me with iPhones. The default Lifetime configuration in rad.conf is enabled. When the iPhone has been in sleep mode for 40 minutes and then wakes up, it's disconnected from the Wi-Fi network.

The lifetime must be set to a value at least 3 times the value of MaxRtrAdvInterval (which is defined in RFC 4861 as a maximum of 1800 seconds). There is no maximum value defined in the RFC for an RDNSS lifetime. Therefore, for those who care, as long as we set our RDNSS lifetime to more than 5400 seconds, we can guarantee that we are within the specifications of RFC 8106.

[OPNenthu]

Is there a way to set this on Dnsmasq?  I'm reading that it sets the RDNSS lifetime to the RA lifetime, but I don't see a specific option for it.

We have an older generation iPad here that sometimes fails to connect on wakeup (not consistent), but it does still show the IPv4 DNS in Settings when this happens so I"m not sure it's the same bug.  It only recovers with a device restart.

[Javier®]

Can't configure AdvRDNSSLifetime in Dnsmasq Opnsense?

[OPNenthu]

I can change the RA lifetime on a range but I think I cannot independently change the RDNSS lifetime.  Could be wrong.

[Javier®]

I don't know if it can be changed, can it be done manual

Recursive DNS Server (RDNSS) lifetime in Router Advertisements (RAs) is automatically managed based on the shortest lifetime of the preferred address on the interface. While RDNSS support adheres to RFC 8106, Dnsmasq does not provide a direct configuration option to set an explicit RDNSS lifetime value.

[OPNenthu]

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014753.html

Does this mean it's tied to the DHCPv6 lease time rather than the RA lifetime?  I'm not sure how to interpret it.

[Javier®]

Hi everyone, I don't know how Dnsmasq works configuring pltime is not the same as configuring RDNSS
In opnsense, dnsmasq can be used in conjunction with radvd and used explicitly.

interface vlan123 {
  RDNSS 2001:db8:cafe:beef::1 {
    AdvRDNSSLifetime 604800;
  };
};

The problem is that on many devices, when lifetime RDNSS is not configured, the IPv6 DNS disappears, and with an IPv4 and IPv6 connection, the device will only have IPv4 DNS.
It is also recommended to configure in interface, preferred and valid lifetime to avoid disconnections.

interface igc1 {
  prefix 2a01:xxxx:xxxx:xxxx::/64 {
  preferred lifetime 86400
  valid lifetime 108000
  }
}

  dns {
  lifetime 604800
  nameserver {
    2a01:xxxx:xxxx:xxxx::1
  }
  search {
    home.arpa
  }
}

[franco]

I'm a bit puzzled by this.

Android trying to reach a GUA from a link-local source address is the level of competence we're dealing with here.


Cheers,
Franco

[rmayr]

I'm a bit puzzled by this.

Android trying to reach a GUA from a link-local source address is the level of competence we're dealing with here.


Cheers,
Franco

In my tcpdumps above, I replaced my GUA prefix as supplied by the ISP through PD with <myprefix>. This doesn't refer to the ULA range I use (which is also on the respective VLANs, but does not seem to interfere in the behaviour I am seeing).