IPv6 SLAAC addresses for all LAN interfaces configured on host (RA received for all interfaces)

zidour · April 15, 2023, 9:46pm

I have a /48 prefix assigned from the ISP and this has always worked fine for me. Recently I created a couple of inernal/LAN interfaces (using VLANs), mainly to separate the traffic on various home networks, and assigned a /52 sub-prefix to some of them.

Unfortunately the Windows machine hooked up to the port on Omnia seems to receive router advertisements from all the networks, hence breaking local IPv6 connectivity. I think I am doing something wrong - perhaps something I misunderstood about the set-up, but can’t see what that is.

First, the set-up:

config device 'br_lan'
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan0'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option _turris_mode 'managed'
        option ipaddr '192.168.1.1'
        option ip6assign '52'
        option ip6hint '0'
        option device 'br-lan.5'

config interface 'mgmt'
        option proto 'static'
        option ipaddr '192.168.2.1'
        option ip6assign '52'
        option ip6hint '1000'
        option netmask '255.255.255.0'
        option device 'br-lan.20'

config interface 'dmz'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6hint '2000'
        option ipaddr '192.168.3.1'
        option ip6assign '52'
        option device 'br-lan.30'

This should cause the machines on the lan network to receive IPv6 addresses with prefix X:0, machines on the mgmt would get prefix X:1000, and dmz would get X:2000, where X is the prefix assigned by the ISP.

VLANs are set up like this:

config bridge-vlan
        option device 'br-lan'
        option vlan '5'
        list ports 'lan0:t'
        list ports 'lan1'
        list ports 'lan2:t'
        list ports 'lan3'
        list ports 'lan4:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '20'
        list ports 'lan0:t'
        list ports 'lan2:t'
        list ports 'lan4:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '30'
        list ports 'lan0:t'
        list ports 'lan2:t'
        list ports 'lan4:t'

This is bridge vlan:

port              vlan-id
lan0              5
                  20
                  30
lan1              5 PVID Egress Untagged
lan2              5
                  20
                  30
lan3              5 PVID Egress Untagged
lan4              5
                  20
                  30
br-lan            5
                  20
                  30

I.e., lan0, lan2 and lan4 are all-tagged trunk ports, and lan1 and lan3 are untagged VLAN5 ports, and both these ports have a Windows 11 machine on the other end of the wire.

This is what the Windows ipconfig shows (X stands for the provider-assigned /48 prefix):

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan
   IPv6 Address. . . . . . . . . . . : X::102
   IPv6 Address. . . . . . . . . . . : X:0:2944:90d8:6510:4a56
   IPv6 Address. . . . . . . . . . . : X:1000:6e43:58e5:769e:72c
   IPv6 Address. . . . . . . . . . . : X:2000:bbec:612f:fe:5049
   Temporary IPv6 Address. . . . . . : X:0:507f:9ea:db7c:3c78
   Temporary IPv6 Address. . . . . . : X:0:5524:bd2f:fe7a:2631
   Temporary IPv6 Address. . . . . . : X:0:84cc:b2b6:44f2:db8a
   Temporary IPv6 Address. . . . . . : X:1000:ad4c:de8f:174:b09b
   Temporary IPv6 Address. . . . . . : X:2000:ad4c:de8f:174:b09b
   Link-local IPv6 Address . . . . . : fe80::a167:a916:58ec:bbab%9
   IPv4 Address. . . . . . . . . . . : 192.168.1.102
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::da58:d7ff:fe00:3738%9
                                       192.168.1.1

As you can see, the machine autoconfigures SLAAC addresses from all IPv6 configured interfaces on Omnia, despite being connected to lan3/br-lan.5 only.

And indeed, if I run Wireshark on the Windows machine, I can clearly see router advertisements for all the networks (X:0, X:1000 and X:2000) reaching the computer. What is weird is that when I run tcpdump on br-lan.5, I can only see the correct (X:0) router advertisements. tcpdump on lan3 shows no router advertisements (but honestly I am not sure if that’s expected or not).

Finally, some ip command outputs on Omnia (extract):

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1024
    link/ether XX:XX:XX:XX:XX:39 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether XX:XX:XX:XX:XX:39 brd ff:ff:ff:ff:ff:ff
5: lan0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
9: lan4@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
14: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
15: br-lan.5@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
17: br-lan.20@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff
18: br-lan.30@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:38 brd ff:ff:ff:ff:ff:ff

# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 state UP qlen 1024
    inet6 xxxx:xxxx:xxxx:xxxx:3738/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1024
    inet6 ISP_END::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:3739/64 scope link
       valid_lft forever preferred_lft forever
14: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 xxxx:xxxx:xxxx:xxxx:3738/64 scope link
       valid_lft forever preferred_lft forever
15: br-lan.5@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 X::1/52 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:3738/64 scope link
       valid_lft forever preferred_lft forever
17: br-lan.20@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 X:1000::1/52 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:3738/64 scope link
       valid_lft forever preferred_lft forever
18: br-lan.30@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 X:2000::1/52 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:3738/64 scope link
       valid_lft forever preferred_lft forever

(xxxx:xxxx:xxxx:xxxx is the same link-local prefix everywhere, X is the provider assigned /48 prefix)

Any idea what the problem is here? Would it help to force different MAC address for each of the br-lan.5, br-lan.20 and br-lan.30 interfaces? IPv4 seems to be working perfectly fine in this setup.

NB: there is a managed switch behind one of the trunk interfaces (lan0) and the computers behind that switch (with untagged ports) configure all the SLAAC addresses correctly.

zidour · April 16, 2023, 9:25am

Tried to manually assign different MAC addresses to each br-lan.n interface but that did not help - still receiving RA for all the local networks.

zajdee · April 16, 2023, 10:30am

Is your Windows station connected to a port with multiple VLANs configured? If yes, you may be seeing the issue with Windows stripping the VLAN tag from packets and applying RAs from all the VLANs. Windows require a port with single untagged VLAN and no tagged VLAN to operate correctly.

Some drivers allow for VLAN configuration that really works (in other words, only use the one configured VLAN and drop traffic from all other ones), but most drivers fail in this job and simply let all packets through.

In the IPv4 world the issue was hidden because the outgoing traffic is typically untagged, so the DHCPv4 exchange (which is initiated by the client) is only performed on the untagged VLAN. RAs are sent by the router and multicasted to all the stations on the VLANs and that’s why we see the issue now.

zajdee · April 16, 2023, 10:38am

In the wireshark dump on Windows, do you see some tagged RA packets from other VLANs? The configuration in the first post suggests Windows should be on the untagged post only, but in that case there should be no RAs from other VLANs. So maybe the switchport config is incorrect.

zidour · April 16, 2023, 11:21am

The two impacted Windows machines are connected to lan1 and lan3 ports of Omnia. I think I posted all the relevant configuration in my first post, but let me know if there’s something else I missed and could still be interesting.

To recap:

I think this should ensure that lan1 and lan3 are untagged ports on VLAN 5

config bridge-vlan
        option device 'br-lan'
        option vlan '5'
        list ports 'lan0:t'
        list ports 'lan1'
        list ports 'lan2:t'
        list ports 'lan3'
        list ports 'lan4:t'

And this is what bridge vlan shows, again, to me it looks like a correct config for lan1 and lan3:

...
lan1              5 PVID Egress Untagged
lan3              5 PVID Egress Untagged
...

I think I have seen the post you are referring to (and also others, similar), where the conclusion is that Windows are simply stripping any VLAN info from the frames, in case more VLANs are present on the port. However

I think with my config above there should only be VLAN 5 packets delivered to the port (so wondering how come Windows can even see RAs for other VLANs)
I don’t see any VLAN ids on the captured frames at all, but that might be either because Windows are stripping them as above or I just don’t know where to look

To make this even more interesting, I have just hardcoded VLAN 5 in the windows network interface driver and the problem is gone.

So either VLAN configuration on Turris/OpenWRT does not work as advertised (I seriously doubt it, there would be tons of bug reports), or there is something missing in my config, but I just can’t see what that is.

Ondrej_Caletka · April 16, 2023, 5:06pm

I think this is exactly the case. And yes, there is an open bug report. As a workaround, you can stop using broken VLAN filtering in the switch chip and use separate bridge interfaces for each VLAN instead. This should work without issues, however intra-vlan traffic will flow via the CPU, which is less efficient.

Ondrej_Caletka · April 16, 2023, 6:21pm

This thread made me finally look for a workaround, since the problem prevails in TOS 6.3.1. So the least intrusive method is this, let’s suppose that I want to use lan1 as an access port for VLAN 60 with no other tagged frames allowed:

config device
        option name 'br-local'
        option type 'bridge'
        option bridge_empty '1'
        option force_link '1'
        list ports 'lan1'
        list ports 'br-lan.60'

config interface 'localbr'
        option proto 'none'
        option device 'br-local'

Make sure to remove lan1 from both br-lan device config and also all bridge-vlan configs. I can confirm that after this change, no 802.1q-tagged frames are leaking from the lan1 port so it should be safe-for-windows (SFW )

zidour · April 16, 2023, 6:25pm

Oh wow, thank you very much, Ondřej. I was so sure I must have been doing something wrong I did not even look into the Turris bug reports (and it did not come up in Google search).

That explains it, thank you. Hope that this does not end up being too hard to crack for the Turris team.

system · April 19, 2023, 6:25pm

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.