Wireguard over IPV6 with Starlink, IPV4 ok, no ipv6 route

[KipK]

and here is the tcpdump from eth0 ( wan ), and it seems to get out

17:03:48.421951 IP6 2a0d:xxxx:xxxx:xxad:xxxx:xxxx:xxxx:xxxx.52530 > 2a00:1450:4009:81d::200e.443: Flags [S], seq 3404923316, win 65535, options [mss 1220,sackOK,TS val 3540499890 ecr 0,nop,wscale 9], length 0
17:03:48.422025 IP6 2a0d:xxxx:xxxx:xxad:xxxx:xxxx:xxxx:xxxx.52534 > 2a00:1450:4009:81d::200e.443: Flags [S], seq 1764043911, win 65535, options [mss 1220,sackOK,TS val 3540499890 ecr 0,nop,wscale 9], length 0
17:03:48.469390 IP6 2a00:1450:4009:81d::200e.443 > 2a0d:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx.52534: Flags [S.], seq 3129180539, ack 1764043912, win 65535, options [mss 1440,sackOK,TS val 2436081721 ecr 3540492655,nop,wscale 8], length 0
17:03:48.469526 IP6 2a00:1450:4009:81d::200e.443 > 2a0d:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx..52534: Flags [S.], seq 3129180539, ack 1764043912, win 65535, options [mss 1440,sackOK,TS val 2436081721 ecr 3540492655,nop,wscale 8], length 0
17:03:48.469576 IP6 2a00:1450:4009:81d::200e.443 > 2a0d:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx..52530: Flags [S.], seq 2085435908, ack 3404923317, win 65535, options [mss 1440,sackOK,TS val 681670550 ecr 3540492614,nop,wscale 8], length 0
17:03:48.469634 IP6 2a00:1450:4009:81d::200e.443 > 2a0d:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx..52530: Flags [S.], seq 2085435908, ack 3404923317, win 65535, options [mss 1440,sackOK,TS val 681670550 ecr 3540492614,nop,wscale 8], length 0

[mk24]

@KipK

don't get where this LL fe80::200:5eff:fe00:101 is coming from.

That is the link-local of your Starlink modem on the wan network, which is where to forward packets destined for the Internet. Since link-locals are link specific, you need to specify the interface to ping it:
ping -6 fe80::200:5eff:fe00:101%eth0
Of course its configuration has to be to answer pings.

[mk24]

and then are those https replies (you've xd out the 56 prefix, which should be ad for the phone) observable going into the tun0 interface?

[KipK]

edit: the /56 prefix requested by wan6 is xx00
xxad is the /64 prefix delegated to gw0
xx00 is the /64 one delegated to br-lan

I don't see those http replies going into wg0 thereafter, well spoted.

But what would block the inward traffic then. My fw rules looks ok.

[KipK]

Good news II got the culprit, and still wondering how the heck I've found that

The problem comes from mwan3 interfering with IPV6 ( but only with wg ) .
I've disabled mwan3 completly ( as I don't use it anyway ), and nows everything route ok , problem solved.

Thanks for your help @mk24 @egc

[egc]

Great you solved could not imagine that

[KipK]

me neither, thanks to this post that gave me the correct trail :

How to properly setup IPV6 with a VPN?

seems it also impacts wg server

[KipK]

Last thing, I've managed to make it works with fixed /128 on android too. Seems with all the different problems I got, it was not a SLAAC issue.
Using SLAAC solve the problem of dynamic IPV6, but as talked above, will need a separate WG interface for each client. And I got also some RA expirations issues I couldn't figure out yet.

As my /56 hasn't moved for a month now, I suspect starlink start to switch to stable IPV6-PD, and that would be a good news.
I've changed the wg config to use fixed /128 for each client on the same interface, and it works.
If the ipv6-pd change in the incomings days/weeks, I'll script something to update the wireguard config automatically if the prefix change.