AP leaking VLANs?

chmeee

I have a bizarre situation with my NWA210AX. I have 4 SSIDs, each one with a different VLAN tag. I've only used two of the SSIDs recently (in the last year), and only connected to one of those for testing purposes after enabling IPv6 on my network. However, now any device connected to this AP on my primary SSID gets IPv6 RAs from both VLANs (SSID-1's and SSID-2's). Has anyone else seen anything like this?

Some network infrastructure details:

pfSense router, managing all VLANs

ZyXeL GS1920 switch, with trunking enabled on the AP's port and the router's port, allowing tagging on all other ports, VLANs configured on the switch as well.

NWA210AX with 4 SSIDs, VLAN 1 is primary, and 3 other VLANs.

I ran tcpdump on both a MacBook Pro connected on WiFi, and a Linux machine connected to the primary network, looking at RA packets (`tcpdump -vvvv -n -i en0 icmp6 and '"ip6[40] == 134"`) (Linux interface on my Linux device, of course), and only my MBP sees the RAs from the other VLAN. But the problem does affect my Android phone as well, where it gets IPv6 addresses in both spaces.

Has anyone seen anything like this? Any thoughts on how to dig deeper, or fix the problem? I've spent several hours looking at this and haven't come up with anything. Since my second SSID is not currently used, I've disabled that VLAN at my router until I can solve the problem.

Zyxel_Judy

HI @chmeee ,

Based on your description, we have outlined the scenario as follows. Please let us know if any details are incorrect.

To assist you further, kindly provide the NWA210AX configuration file along with the tcpdump files. Please note which tcpdump files are from Linux and which are from the MBP.

chmeee

Your picture is close, but the Linux machine is connected to the switch, not using wifi. MBP and Android devices are on SSID-1 but getting IPv6 RAs from the VLANs for both SSID-1 and SSID-2. As requested, I've attached the tcpdump output from both my MBP and Linux devices, along with a (slightly sanitized) startup-config from my AP. I hope I'm just missing something obvious in my config. If needed I can provide the config for my GS1920 as well.

(Deleted the files, can share them in a DM again if needed)

Zyxel_Judy

HI @chmeee ,

Upon analyzing the logs, we suspect this issue is related to the IPv6 with SLAAC mechanism. Please verify if the IPv6 with SLAAC mechanism is enabled on the pfSense router.

If possible, please:

1. Disable this mechanism
2. Retest the connection
3. Inform us of the results

chmeee

I want to use IPv6 SLAAC on all VLANs; additionally, RA's are required for IPv6 to work. The problem I have is that devices connected to one SSID (so one VLAN) are receiving RA's that are intended for another VLAN. This is not a router issue, else I'd be receiving RA's from VLAN 8 on my Linux and FreeBSD devices, but I only receive them on devices connected to WiFi, and from my test (2 MBPs, 2 Android devices), all devices, even those that have never connected to VLAN 8, receive these RA's. Is there something wrong with my configuration of the AP? Or is this a known behavior of the AP that cannot be changed? I hope it's a simple configuration issue that can be fixed. IPv6 SLAAC over VLANs seems to be a very basic thing that any router, AP, or switch should need to handle.

Zyxel_Judy

HI @chmeee ,

We correct the typology as below：

Could you connect the MBP and phone to wireless network again and then download the AP diagnostic and Switch config files (startup-config file) for our check?

At the same time, capture vlan tag packet on linux pc > tcpdump -i eth0 -v -e icmp6 and 'ip6[40] = 133'

If AP is in standalone mode, could we have the remote session with you or you connect the AP to NCC? We need to monitor the packet of eth0 on NWA210AX to see if it has the correct vlan tag.

chmeee

I 'resolved' the problem by tearing down my guest network and rebuilding it from scratch, all the way back to the router's VLAN configuration, choosing a different VLAN ID. I'm still really confused why it was happening in the first place, but it's not anymore.