Guest network allowed to ping local workstations?

[svk253]

Hello,

I started to play around with nmap on the guest network I just set up to test the security. It appears that my client, while connected to the new guest network, can discover all of the workstations on our LAN. I don't think it can do much else. But should it be able to do that?

We have another guest network for vendors that is on another VLAN and is restricted via ACLs on the switches, and it cannot see the other workstations.

I have the firewall rule set up as Deny Any to the local LAN (see screenshot). Thank you.

[Dylan_YYC]

I see you have Layer 2 LAN isolation turned off, i would turn that on and it should stop that behavior. 

[svk253]

Hi Dylan,
I thought that too, but it will only let me select that option if I am in bridge mode for the SSID. I am using Meraki NAT so they are isolated from our LAN.
Thanks!
Sandra

[WadeAlsup]

Ping uses ICMP rather than TCP or UDP protocols on a separate layer of the OSI model.

See this thread for more about blocking ICMP on an MX device. 

[svk253]

But the Deny Any / Any to the local LAN would not block ping? I don't really want our servers and workstations discoverable by the general public. I can try to add a separate rule to block ICMP and see how it goes. I find it weird that Meraki APs allow that to begin with between the isolated guest network and the LAN.

[WadeAlsup]

Truthfully I haven't tested blocking ICMP traffic as I haven't seen the need in my own environment.  

Think of it more as flexibility of configuration. Just because you use NAT mode with Meraki DHCP on your ssid and call it an "isolated guest network" does not mean that it has to be. You can offload DHCP for clients and still allow them to have access to network resources. 

[svk253]

I get it, but I can discover IP's, MAC addresses and DNS names of every workstation on my local LAN. Someone coming in off the street shouldn't be able to do that. We need to have the guest network as isolated as possible. I asked in another post about how to do that without having to bring in a physically separate ISP, or VLAN it off, and Meraki NAT should be the answer, no?

[BrandonS]

It should be blocking as you expect.

I suspect that there may be a flaw in your testing.  Did you set the deny recently while trying to solve this?  If so it may not have taken effect on current network flows yet.

Is it possible the machine you are testing from is also connected to wired LAN while connected to the guest wireless?

[svk253]

It doesn't appear to be blocking yet... does this look right? I did just set it. (see screenshot). The client I am using is completely disconnected from the LAN, no cables. It's just on the guest SSID.

What other things do I need to add to make this SSID bulletproof? They should *only* be able to get to the internet. I sort of thought that was the case already, but now I am paranoid, lol.

[BrandonS]

I don't think you need to specify ICMP, but I could be wrong and it shouldn't hurt.

I would try just rebooting the machine you are testing from or maybe delete the wireless connection and connect again.  Some changes in Meraki like this can't take effect immediately because active network flows won't be updated. 

[Adam]

If the computer you are testing from is 'whitelisted' it'll be exempt from that deny rule.  I found that out the hard way when doing testing. Otherwise that rule should work as long as you are definitely on the SSID that rule is being applied to.  On that page verify the SSID drop down just above the screenshot you posted.  And also check the client to make sure they are connected to that SSID and not inadvertently connected to a different one. 

[braham2019]

I've experienced the same issue (local LAN accessible through guest network). And I also tested this with a whitelisted client. Thanks Adam, you've pointed me in the right direction! I can safely say my guest network is isolated now.

[WadeAlsup]

@BrandonS is correct. You want to make sure that you fully disconnect and let the dashboard recognize that before reconnecting your client to test. 

Also verify that you do not have any policies applied to the client. 

I'll create a test ssid here to see what I can come up with. 

[svk253]

It's set up pretty simple, the only thing I specifically enabled for the SSID besides the firewall rules is the splash page (no login, users can click through). The Deny All rule has been there for a few days, I just added the ICMP rule. No group policies. I don't *think* the client is whitelisted, but how would I check that?

SSID drop down is on the correct SSID, let's say Company_Public. Client is connected to Company_Public.

[Adam]

---

@svk253 wrote:
It's set up pretty simple, the only thing I specifically enabled for the SSID besides the firewall rules is the splash page (no login, users can click through). The Deny All rule has been there for a few days, I just added the ICMP rule. No group policies. I don't *think* the client is whitelisted, but how would I check that?

SSID drop down is on the correct SSID, let's say Company_Public. Client is connected to Company_Public.

---

Go to Network Wide>Clients, search for the client and check what policy is assigned.  

[Adam]

I also just did a test of this to make sure it wasn't something that got broken with a firmware update.  It is blocking as expected except I noticed that anything I was able to ping from my test laptop when on the trusted network I could still ping when I moved to the "Public" network.  Although if I tried to ping other stuff I couldn't.  So it likely has some streams cached.  

[Adam]

---

@Adam wrote:

I also just did a test of this to make sure it wasn't something that got broken with a firmware update.  It is blocking as expected except I noticed that anything I was able to ping from my test laptop when on the trusted network I could still ping when I moved to the "Public" network.  Although if I tried to ping other stuff I couldn't.  So it likely has some streams cached.  

---

And that cleared up.  I can no longer ping the device that I previously could.  The only thing I can ping, in the entire LAN subnet, is the AP's IP I'm connected to.  Everything else is not pingable.  

[svk253]

The policy says 'Normal' when I check it. Maybe I'll try a different machine or my phone tomorrow. The particular client I'm using was previously on the LAN at one point, but not recently.

I did reboot the client and it's been some time, but ping is still working. Can I kick the client off through the AP to clear those streams? I'm looking but haven't found it yet.

Thanks for taking a look at it so thoroughly though! We would much rather do this than bring in a separate ISP. But only if it is secure.

[Adam]

Out of curiosity what are you pinging?  Do you have a few different clients on the LAN you can ping to test/verify?

[svk253]

I am using nmap to do a scan and it reports that the workstation is up and it can resolve its name (guessing the quick scan uses ping). I'm scanning the entire subnet.
When I ping anything on the LAN using CMD it gives replies but it says net unreachable.

[PhilipDAth]

The deny local LAN access rule "built in" blocks access to RFC1918 address space.

Are you using this on your local network?  Or are you using public address space?

[svk253]

Our local network is 10.0.0.0 /24. I just added that explicitly, and tried really hard to make sure my client was not still using the same stream... deleted the wireless network, turned off wifi, rebooted. Still, it can see our workstation IPs.

I have yet to try a different client, so I'll do that and compare.

[Adam]

I just did a little more testing on this as well.  In many cases ping replies show as filtered from 10.128.128.128 which isn't an actual reply from the client.  I also ran Zenmap (I'm not smart enough to figure out the command lines for nmap) and it returns the mac address of the AP for the host so it isn't technically responding.  So I'd be curious what kind of response you are actually getting in reply to pinging clients.  

[svk253]

I do see the MAC address of the Meraki AP. But I also see a list of host names plus their IP addresses, and it claims that the hosts are up. Is this the AP responding?
Why would I see the computer name and IP of all the different workstations? I can see the domain name and PC name thru ping, and if I run a quick scan sometimes I can see the operating system it's running...like it's the actual domain name and IP. If I try to ping any of those with CMD it comes back with unreachable from 10.128.128.128 but I would think it should time out, instead?

I cleared ARP and DNS cache on the client. No change.

[svk253]

Hmm, I added a switch to my scan and now it says 'host is up, received arp response'.

[Adam]

The name/DNS of the client shouldn't resolve unless your giving your public wifi clients your private DNS server?  This may be the case by default where it forwards the DNS request upstream.  To avoid this I set custom DNS on our public wifi to by going to Wireless>SSID and editing the public SSID and setting it as follows.

With the above configuration I cannot ping the name of a client.  If I ping the IP of a client in my LAN it gets replies from 10.128.128.128 and the MAC of the AP so that traffic isn't actually reaching the client.  

Edit:  If you look at that response from the switch it will likely show the MAC of the AP you are connected to.  

[svk253]

Ok, interesting! If I switch the DNS to custom and use the ones you used as a test, I cannot resolve the PC name. The ping replies as unreachable from 10.128.128.128. However, nmap still can resolve the name... I don't understand why that is. Tried clearing DNS cache, restarting... Weird!!

Next step is to find a client that hasn't been on our network and run nmap...

[BrandonS]

I wonder if this has to do with your local network overlapping the guest network Meraki uses (10.0.0.0/8)?

[Adam]

---

@BrandonS wrote:

I wonder if this has to do with your local network overlapping the guest network Meraki uses (10.0.0.0/8)?

---

I thought that when I originally configured it as well but it doesn't cause an issue.  We also use 10.0.x.x/24 networks for some of our LANs.  With the config above and using nmap from my laptop I was unable to resolve the name of the computers I tested against.  I tried a few of the clients/servers on our network and it just showed the MAC of the AP.  

[svk253]

Could it have anything to do with the fact that the client I'm using is joined to the domain? I'm not logged in as a domain user though, I'm using local admin.

Just tried on a different client, a brand new laptop that was just set up. Unfortunately, also on our domain. Nmap resolved the names somehow.

[Adam]

---

@svk253 wrote:
Could it have anything to do with the fact that the client I'm using is joined to the domain? I'm not logged in as a domain user though, I'm using local admin.

Just tried on a different client, a brand new laptop that was just set up. Unfortunately, also on our domain. Nmap resolved the names somehow.

---

It shouldn't, I tested from my domain laptop and it wasn't able to resolve the names.  You may need to run some nslookup commands to identify how it is getting names without having access to the LAN DNS server.  When on public they should be using those external DNS servers which do not have your client names. 

[svk253]

Ok, so it says default server unknown. I feel like maybe nmap is giving me misleading information.

I am trying an experiment...maybe this is off topic, but if I set the SSID to Layer 3 roaming, and put it on our 'guest' VLAN that has ACLs protecting it from the LAN, then...would that work?

I don't know how all of the other branches will handle Layer 3 roaming, because they each have their own Comcast or whatever router and DHCP is set up on that. They don't really come back to our network or VLANs. But the SSID is on all of these APs.

[NetworkingGuy]

I skimmed so I apologize if I missed a diagram of your network. Why not just move your gateway and segment?

We use MX100s at the head of our network and MS425s or MS350s on the LAN side for routing our VLANs out the MX.

Our ISPs are in WAN VLANs. I allow them to connect to their VLAN on 1 port and our FW interface on another. 

The downstream link to our LAN does not include this WAN VLAN.  2 ISPs - 2 WAN VLANs. 

If you do this, then HA and VRRP and what not work but it keeps public networks out of the LAN.

Our NOC Network is the native VLAN I use for management of our Meraki network gear. Its gateway is on the MX.

Our Guest network default gateway resides on the MX100s we have (2 for HA and VRRP) in its own VLAN. 

Our user networks default gateway resides on the MS425s or MS350s. 

I setup a simple route on the MS425s or MS350s 0.0.0.0/0 to MX NOC IP. 

When users need an AP I set all the SSIDs to be assigned to a VLAN and then I tag that VLAN on their interfaces with native VLAN as my NOC. 

Like this, our LAN subnets can ICMP each other without issue and ping stuff in the Guest network.

The Guest can't reach the LAN though unless I allow it. Since its for guests I don't care.

I use Google DNS for them and that's it. That way you don't have to add as many Firewall rules.

[svk253]

Thanks for your suggestions NetworkingGuy, I would like to implement something a little cleaner someday, but this is sort of the minimum viable product at the moment... Our public wifi is sort of an add-on to internal staff wifi that we've had for a while. Branches already have contracts for their own ISP separate from the WAN link back to the main office, but they have no staff network. The main office is different because we have the staff network too.

On another note.... here is where I ended up: I grabbed a client and set it back to clean factory defaults, just plain old Windows 10 and downloaded nmap. Did a ping scan and STILL, it could somehow pull up the names of our workstations.

So, I went ahead and changed the DNS again to 208.67.222.222 and tried a ping scan. Sure enough this time the names did not show. So, I don't know if nmap saw our internal DNS server somehow? I am really at a loss. But if this is the case I'm going to do some more testing to see if we can still use Meraki NAT / DHCP.

Thank you everyone for your time and insight!

[JonathanH]

I know this is an old post, but maybe it will help someone.

We have 4 SSIDs, one private, 3 for different types of guests.  One of these guest SSIDs was allowing the client to traverse into the network.  It was not able to do name lookup, but it could ping, and attach to other services.  

In the Access Control section\Captive Portal Strength:  we had ours set to "Allow Non-HTTP Traffic prior to sign-on."

We also run a Splash Page on this SSID, and we have our Firewall rule set to Deny LAN traffic.

What we discovered is that the Firewall rule does not kick in until the Splash Page is acknowledged.  If the client never opens their browser to Ack the splash page, they are unrestricted.

If you set your Captive Portal Strength to: "Block..." everything works as you would expect, and the client is prevented from LAN access.

Here's a link describing exactly what's happening:

Troubleshooting Users' Network Access with Splash Page Enabled

Personally, I don't believe that this is intuitive, and is not addressed well (at all?) in the Dashboard, and the results of this misconfiguration could be really bad.  This is a security hole and Cisco needs to either enforce "Block" or remedy this to prevent clients free access to everything until they are allowed.

What's even stranger.... one of our SSIDs was set the same way, and couldn't get to the private LAN.  

So the problem isn't consistent, and that's frustrating.

Shout out to Support for linking me the above document.

[Duke_Nukem]

Back from the dead again...

We recently had a Network Security Assessment done and the assessor informed us of the ability to see the internal/private LAN when on the Guest wifi network using nmap.  My settings are the same as the original poster - Deny any to the Local LAN.  AND the Captive Portal strength is set to Block all access until sign-on is complete.  

They could see all machines on the local LAN and discover open ports/services.  

This isn't the behavior I thought we had in place.  Not good.  Not happy.

[Brons2]

I also add explicit deny/any to all our internal subnets on the guest wireless SSID firewall rules.  On top of that, the guest wireless is pure L2, and the default gateway is the (non-meraki) firewall which for sure isn't going to let wireless clients get out of line.

The SSID L3 firewall rules do now allow an explicit ICMP deny, so maybe for some of the people that tested back in April, that is a new feature.  I don't recall it being there when I originally set the wireless up on Meraki gear some years ago.  But now ICMP is in the dropdown on the "Protocol" column.

[Duke_Nukem]

Opened a ticket with Meraki last week.  Confirmed with them via packet captures that a client on the Guest wifi could talk to servers on the internal LAN.  Was able to telnet via port 53 to our DNS/AD servers.

Definitely a bug in their setup.

Temporary fix was to add the explicit "deny any 192.168.0.0/16 any" to all of our WiFi networks that use Meraki NAT mode (Guest, mobile phones, scanners).

[PhilipDAth]

That rings a bell!  DNS and DHCP are excempt from the "deny local LAN" rule.

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

"Note: DNS and DHCP traffic is exempt from this rule. If the SSID is in NAT mode, only DNS traffic is exempt since the AP acts as a DHCP server for connecting clients."

[Duke_Nukem]

That's great, but do a search for a tool called Iodine.  Port 53 needs to be blocked.  The tech I had on the call showed me the tool and how it can be used in this scenario.  Eye opening...

[PhilipDAth]

I don't think anything in the Meraki arsenal can block the port 53 VPN solutions at the moment.