MR36 Deny Local LAN Does Not Block Traffic to LAN and bypasses MX84 firewall.

KenLux
Here to help

MR36 Deny Local LAN Does Not Block Traffic to LAN and bypasses MX84 firewall.

Hi,

 

We have a MX 84 as our externally facing firewall and a MR 36 access point. The MR 36 is presenting 4 SSIDs. Only 1 is supposed to be able to access anything but the internet - all others are supposed be "guest" SSIDs. The MR 36 is in NAT mode and we set the Layer 3 firewall rules as described here:

https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/'Deny_Local_LAN'_settings_in_Cisco_...

 

These SSIDs provide IP addresses in the 10.0.0.0/8 range.

 

The 1 SSID that is supposed to have access to the LAN resources is set up as a VPN tunnel to the MX84 and receive IP addresses from our (non-Meraki) DHCP server in the 192.168.1.0/24 range.

 

However, clients attached to one of the guest SSIDs are able to connect to computers on the 192.168.1.0/24 LAN.

 

Is Meraki planning on fixing this?

7 Replies 7
Brash
Kind of a big deal
Kind of a big deal

A few things to confirm:
 - Is it only a single guest SSID that you're seeing can reach the 192.168.1.0/24 LAN?

 - Are those guests receiving a 10.0.0.0/8 IP from the AP?

 - Are the firewall rules configured on the MX or on the MR?

 

Are you able to provide an output of the applicable firewall rules currently configured?

KenLux
Here to help

1. We've only tested the one guest SSID

2. Yes, they are receiving IP addresses in the 10.0.0.0/8 range

3. Firewall rules are enabled on both MX and MR. MX has all outbound ports open, only 3 ports open (none of which is the port the clients are using). MR is configured as in the article - except I have added two new level 3 rules to try to stop the access:

a. Deny all to 192.168.1.0/24 on any port

b. Deny all to <external IP> on any port

 

Bruce
Kind of a big deal

@KenLux, last time I used the 'Deny Local LAN' setting it worked fine, in fact its one of those things that normally catches people out as its the default setting.

 

I'm a little intrigued as to how you are using your MX84 for both an externally facing firewall and also to terminate a VPN tunnel from a MR. Generally to achieve this the MR must be making a connection to the WAN interface of the MX84, which would suggest that your MR is on the public network, or you have some interesting routing happening.

 

Are you able to provide a diagram of what you have setup as it sounds more like there is something not quite right, rather than the 'Deny Local LAN' rules not working.

KenLux
Here to help

Our layout is pretty simple:

Internet<--->MX84<--->MR36<--->WiFi Clients

 

The LAN interface on the MR36 gets its IP address from a DHCP server on the 192.168.1.0/24 LAN (not the MX84).

The non-guest SSID is set to "VPN tunnel data to a concentrator". So maybe this should be set to bridge mode instead to make sure that the MR36 knows that the 192.168.1.0/24 subnet is a local LAN as opposed to the internet. Perhaps choosing the VPN tunnel setting makes the MR36 think that the LAN interface it is connecting to is the internet, and so it allows traffic on that interface?

 

I'm really not sure why we chose the VPN tunnel instead of bridged mode. But I'm surprised that it would make a difference. It would be just a tunnel inside the LAN - not necessary, but I would expect it to be functionally the same as bridged mode.

 

Bruce
Kind of a big deal

@KenLux, definitely set the non-guest SSID to bridge mode, it won’t make a difference to what the access point knows, but it’s a more logical solution (and should work better). Then the clients on the non-guest SSID should get an address in the 192.168.1.0/24 range. Make sure the DHCP server is set to provide the gateway of whatever address you’ve assigned to the MX on the 192.168.1.0/24 subnet. For the guest SSIDs double-check that the firewall is configured on all three of the SSIDs on the MR.

KenLux
Here to help

So we set the SSID for LAN access to bridged mode, disabling Layer 2 LAN Isolation disabled (they should name this Layer 2 LAN Client Isolation instead).

 

What is happening now is we have an exchange server behind our MX on the 192.168.1.0/24 subnet. People had their phones set up to connect to it from the internet, and the MX was forwarding traffic incoming on port 443 to port 443 on the exchange server.

 

After Hafnium and ProxyShell attacks we decided to close port 443 on the MX by deleting the forwarding rule. So nobody could get email on their phones. Except..several phones were able to receive email while connected to a guest SSID on the MR  even though the guest SSID has Deny Local LAN applied. The phones appear to be using IMAP to connect and at least one has the email server as our external IP. If, in the MR, I block any traffic on any port to our external IP, they stop receiving email.

 

I assume the MX recognizes that the packets destined for its external IP are ones that it will process, so it doesn't try to send them out to the internet and back in, so maybe they stay on the LAN side of the MX firewall. But when I don't have the external IP blocked, I don't understand how traffic gets to the phones when there is no forwarding rule in the MX to the exchange server.

 

Well, that weirdness aside, it looks like the clients on the guest SSID (10.0.0.0/8) aren't able to reach the LAN IPs (192.168.1.0/24). But it took a while to realize I had to block the external IP of the MX. I still don't know why - the MX should not have forwarded the packets to the exchange server without a forwarding rule.

 

Any ideas?

 

Ken

Brash
Kind of a big deal
Kind of a big deal

That certainly sounds odd.

Even if you destined traffic from LAN to the WAN IP, the MX should only forward traffic to the exchange server if something like port forwarding or NAT is configured. 

Could be worth double checking that the MX has the latest config pulled from the dashboard (under appliance status).

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels