Guest WiFi Clients Ignoring Firewall Rules

kordm
Getting noticed

Guest WiFi Clients Ignoring Firewall Rules

Hi all,

 

I have two wireless LAN networks and a Guest network.

 

LAN 1: 192.168.0.0/24

LAN 2: 192.168.1.0/24

Guest: 192.168.2.0/24

 

I previously had Guest as a NAT mode wireless network, which worked great to isolate clients but I could not identify clients in the Security Center (events showed AP MAC as source). I created a new VLAN and set the Guest SSID as a Bridged Mode network, tagged with the correct VLAN, and configured the firewall as follows:

LAN Isolation: Enabled

Layer 3 Firewall:
1: ALLOW 80/TCP 192.168.0.17/32 "HTTP Proxy"

2: ALLOW 443/TCP 192.168.0.17/32 "HTTPS Proxy"

3: DENY ANY/ANY Local LAN "Wireless clients accessing LAN"

 

Wireless clients get IP addresses in the correct range. Wireless clients are also isolated in the Guest network as expected, they cannot see each other.

 

However, Guest clients can still ping all clients on LAN 1 and LAN 2. So what gives? Is the SSID firewall being overridden somewhere else? When I inspect client details I don't see the "Deny Local LAN" policy but I do see the two HTTP exceptions I made. Even if I make explicit DENY rules to 192.168.0.0/24 and 192.168.1.0/24 I can still ping both LANs.

12 Replies 12
MacuserJim
A model citizen

Are you setting the L3 firewall deny rules on the MR or on the MX? 

kordm
Getting noticed

They're being set under Wireless > Firewall and Traffic Shaping.

 

I don't have the Guest network assigned to a Group Policy.

 

[also a warning would be nice that changing a network's group policy causes the MX to reboot]

MacuserJim
A model citizen

I would suggest doing the deny rules on the MX appliance. I assume you are denying any protocol and any port in your deny rules? Give that a try and let us know how that goes.

 

Also, when you changed a group policy by going to "Network wide > Group policies" and creating/editing a group policy it rebooted your MX? It shouldn't do that, I make revisions like that quite frequently and have never had the MX reboot because of it. If that is the case then I would think it was a poorly timed coincidence or an issue with your MX. 

kordm
Getting noticed

I just tried making a deny any/any rule from [Guest] to [LAN 1] in the MX and I can still ping clients in the LAN 1 network from Guest. I'm at a loss here.

 

I can create or edit Group Policies just fine, but assigning or removing them from networks causes the MX to reboot. This is an MX84.

kordm
Getting noticed

Update: I've set the Guest SSID back to NAT Mode for now.

 

Turns out I was losing connectivity during network updates due to a STP issue with the MS224 + MX84. I had the MS224 connected to the MX84 with two CAT6 cables via ports configured as ACCESS to their respective VLANs. The ports were configured correctly on the switch and router ... but for some reason the MS224 was getting CDP/LLDP packets from ITSELF via those two ports, causing it to throw a VLAN mismatch error and disable my uplink port.

 

I guess I will have to try again, setting the uplink as a trunk port for both VLANs. (LAN 2 uplinks via a separate firewall)

PhilipDAth
Kind of a big deal
Kind of a big deal

Could you post a screenshot of those firewall rules please.

kordm
Getting noticed

Here's the firewall rules for the WiFi network.

 

Guest WiFi RulesI think most of my issues were stemming from the switching issue I described earlier. I'll create a test network and try to set up the same rules later on.

Jeff-US
Conversationalist

I believe the "Local LAN" destination is a bit misleading in the Meraki firewall rules.  It only means access to the subnet the SSID is on.  The only traffic hitting the deny rule is traffic on the subnet of the guest network.  Everything else is allowed.

 

If you want to block traffic to 192.168.0.0/24, 192.168.1.0/24, and other devices on the guest subnet, but allow access to everything else (and your proxies) you would need:

 

allow 80 192.168.0.17/32 TCP

allow 443 192.168.0.17/32 TCP

deny any 192.168.0.0/24 any

deny any 192.168.1.0/24 any

deny any Local LAN any

allow any any any (default rule)

 

If they would need access to DNS servers in LAN 1 or LAN 2 you would need to create access rules for that as well.

 

Jeff

kordm
Getting noticed

Thanks Jeff. I was thinking the same thing at first, but as per the documentation:


Meraki MR Documentation

The 'Deny Local LAN' function located under Configure > Firewall & traffic shaping blocks access from Wireless clients on specific SSIDs to the Local LAN. For the purposes of this firewall rule, Local LAN is described as any destinations in the following private address spaces:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

It also goes on to say that DNS and DHCP traffic are exempt automatically. What you're describing I believe is the Layer 2 LAN Isolation feature.

 

Regardless, I tried setting explicit deny rules to those subnets and they had no effect. I still believe this was a switching issue, so I'll have to try again with a test network after hours.

Jeff-US
Conversationalist

I stand corrected.  I was sure when I set mine up that local lan access was defined the way I thought, but clearly that is not the case.  Any chance the APs couldn't connect up to the cloud to be updated so they never received your firewall rules?

Jeff

MacuserJim
A model citizen

Have you tried adding the deny rules to the layer 3 firewall rules on the MX appliance to see if that makes any difference?

kordm
Getting noticed


@Jeff-US wrote:

Any chance the APs couldn't connect up to the cloud to be updated so they never received your firewall rules?


I'm not completely ruling that out, but the MRs were getting updates otherwise. Updates to SSIDs and VLAN assignments were working correctly, though I did need to reboot 2 of them to get the NAT DHCP working after I reverted the changes.

 


@MacuserJim wrote:

Have you tried adding the deny rules to the layer 3 firewall rules on the MX appliance to see if that makes any difference?fdfd


Tried that, they had no effect. I tried to do a quick packet capture to check the source addresses, but it didn't record any ICMP packets. I didn't have time to investigate further and had to revert back to NAT.

Get notified when there are additional replies to this discussion.