Group policy set VLAN tag leaks mDNS traffic?

[Adam2104]

Is anyone here using group policies to set different VLAN tags, per client, on the same SSID? For example, I have the following:

ssid: foo

ssid access control vlan tag configured: 105

mode: bridged

auth: basic psk wpa2

vlan 105 network: 192.168.5.0/24

vlan 100 network: 192.168.1.0/24

Scenario 1:

Clients without a group policy attached can connect to the "foo" SSID and get an IP address in subnet 192.168.5.0/24 from the DHCP server on VLAN 105. mDNS traffic is seen from the 192.168.5.0/24 subnet. This works as expected.

Scenario 2:

A new client connects to the "foo" ssid. This particular client has a group policy attached that sets the VLAN tag to 100. No other options are configured on the group policy. The client gets an IP address in the 192.168.1.0/24 subnet from the VLAN 100 DHCP server. mDNS traffic is seen from the 192.168.1.0/24 subnet AND the 192.168.5.0/24 subnet. That's wrong, the client exists in VLAN 100, not VLAN 105, and should not see mDNS broadcasts from devices on VLAN105. This can easily be seen using an mDNS discovery tool (Discovery.app from the Mac OS App Store for example) or a Wireshark capture on udp port 5353.

Has anyone else encountered this? This makes group policy assigned VLAN tags completely useless if traffic leaks between VLANs at the AP.

Note, there's no bonjour forwarding / mdns reflectors in play here that could explain this traffic flow. If I build a new SSID that hooks directly to VLAN 100 via the SSID access control settings there are no mDNS broadcasts from VLAN 105 seen on the client device, as expected.

I'm running MR44s on MR 31.1.5.1 and MS120s on 17.1.3.

If anyone has any ideas that would be great.

[Adam2104]

I did a little more investigation here. It would seem that the MR44 is leaking both ipv4 and ipv6 multicast packets sent on the base SSID access controlled VLAN (the default vlan), to clients in other VLANs if those VLANs are assigned via group policy on the client. Specifically it seems to be leaking the 224.0.0.0 multicast range on IPv4 and the ff02:: range on IPV6.

This is especially problematic because leaking the IPV6 ff02:: range causes the client with the group policy attached to received ICMPv6 messages from both its assigned VLAN and also the default ssid VLAN. So, that means the client is getting ICMPv6 neighbor solicitation requests from devices it can't actually respond to. I wonder if it forwards Router Advertisements also, I bet it does.

[KarstenI]

I am not 100% sure this is the cause, and it likely needs some investigation ...

The wireless standard has no feature for individual group keys per VLAN, but only per SSID. With that, each client will see the BC/MC traffic from any other client on the same SSID regardless of the VLAN.

In the general network-wide settings, you can enable the multicast to unicast conversion. Although it should be enabled by default, look if it is disabled in your setup and try enabling it.

[Adam2104]

I disagree that clients on the same SSID will all see the same BC/MC traffic, regardless of the VLAN they’re assigned to. That’s broken. If I assign a client to a particular VLAN they should see link local multicast from only that VLAN.

I decided to test iPSK as a substitute for group-policy assigned VLANs applied directly to clients. This feature works correctly. A client connecting with the PSK for VLAN 105 gets traffic from only VLAN 105. A client connecting with the PSK for VLAN 100 gets traffic only from VLAN 100. There’s no leakage of BC/MC traffic when using iPSK. Only when using client-specific group-policy assigned VLAN tags.

I thought the multicast to unicast conversion feature might be contributing to this, but it didn’t change the behavior. The MR44 is still leaking link-local multicast across VLANs to clients with VLAN tags assigned via group policy.

To confirm I didn’t have something wonky going on that I wasn’t aware of I created a completely new group policy that assigned VLAN 999. VLAN 999 doesn’t exist in my network, anywhere. It’s not trunked on any ports, and there are no devices in that VLAN. Theoretically a client assigned to VLAN 999 using a group policy shouldn’t see any traffic beyond what the client itself generates. In reality though the client still saw all the link local multicast traffic generated in the default VLAN assigned to the SSID.

This feature is broken, and it’s especially bad from an IPv6 perspective given how much of the protocol is based on link-local multicast and ICMPv6. Leaking that beyond VLAN boundaries breaks a lot of things.