Tracing a client IP on a Meraki NAT SSID

CHAadmin
Getting noticed

Tracing a client IP on a Meraki NAT SSID

I'm trying to determine if a student sent a harassing email to a teacher while on campus Wi-Fi. The email was sent from an anonymous Gmail address, not our G Suite Gmail. However, it was received by a teacher on his school-issued G Suite account, so I can look at the headers.

 

Using the IP addresses in the headers, is there a way I can tell if those IPs correspond to a client on an SSID using Meraki NAT? 

18 REPLIES 18
DCooper
Meraki Alumni (Retired)
Meraki Alumni (Retired)

@CHAadminUnfortunately there isn't a way to do this in NAT mode, which is just another reason why I do not recommend using that mode. If you did find the address it would be 10.0.0.0/8 and every AP you have is handing out redundant IPs so you wouldn't know where it came from. I would recommend moving to bridge mode. If you had a MX I could recommend some additional controls to have for backup to dig into logs when things like this happen.

  

When running in bridge mode make sure you turn on isolation mode - https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation

What do you mean "new software product?"

@DCooper Unfortunately, we are running stable firmware on our APs and the most recent stable build is 24.12. The documentation for bridge more client isolation says its is supported starting in version 25.8

 

Hopefully we'll get a new stable firmware build soon, because I'm also missing hosted logs and URL logging.

@DCooper Also, I do have an MX100. What are the recommendations you mentioned for the MX?

DCooper
Meraki Alumni (Retired)
Meraki Alumni (Retired)

@CHAadmin You could enable netflow and collect web traffic via Syslog. Both would provide granularity your looking for. This is making the assumption you remove the NAT mode. This would of allowed you to map back the time period in the email headers to who was on gmail at that given time. Wouldn’t be the silver bullet to finding the culprit but it would allow you to narrow down the computers that were used at that time.

I'm using NAT mode on Meraki APs, and use Syslog to find my issues. It's not a one step process- you can usually find the trouble flow between the destination address and the AP itself (the "outside address" for the AP NAT, hopefully with timestamp. Then... you search on destination address and 10.x addresses that the AP is handing out- possibly with the AP Name as well. It's clunky but far from impossible, but it does suck that Meraki does not provide syslog as well if it's going to do everything else... I use Splunk, and as long as you're willing to do a few steps and can keep it all straight, you can certainly work within the NAT as well for sleuthing around.

Just noticed that a Meraki employee is recommending against the use of NAT mode- I find that odd!

DCooper
Meraki Alumni (Retired)
Meraki Alumni (Retired)

@wirednot Yes, I have experienced multiple “unintended features” , performance issues at high load and no roaming support where I personally (Can’t speak for others) shy away from using NAT mode to my customers.

 

No Airmarshall “Contain on LAN”.

 

I think the only time I have recommended it was a library with low consumption on a guest SSID.  

 

In what setting have you deployed this? Other than logging how has your experience been?

 

 

Interesting- many years ago (over 😎 I was assured that there was no concern with using NAT on APs (beyond roaming). I'm curious what "high load" amounts to in your context. I have around a dozen branch sites, and public IP space is absolutely at a premium for clients (our branches share Class B public IP with our main campus) and the NAT functionality has been generally transparent and tremendously helpful. Roaming no worse than on our Cisco campus network, generally. Good clients switch quick, draggy clients drag. But- no VoIP for us either.

 

When I hear that "you shouldn't use it" my first thought is why does Meraki not message that responsibly right on the UI?

DCooper
Meraki Alumni (Retired)
Meraki Alumni (Retired)

Lee, your designs are always the exception. 🙂  

 

*My opinions aren’t worth much, let’s get that out there.

 

 

 

 

Hmm.

DCooper
Meraki Alumni (Retired)
Meraki Alumni (Retired)

@wirednotMade me think a little more about this, we list out "common problems" and limitations in these documents: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/NAT_Mode_with_Meraki_DHCP#Common_...

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignme... ..

 

However, I do not see the other limitations I mentioned above, no 802.11r, k, v, w and limited AirMarshal features. I will have them add that into the documentation.

 

 

Beyond roaming- I have no concerns with any of the limitations. Bonjour is $hit, shouldn't be used on business networks to begin with, Fastlane is a gimmick, we generally avoid multicast on the WLAN. Still curious about the "high load" thought- given that CPU/memory can't be really seen.


@wirednot wrote:

Beyond roaming- I have no concerns with any of the limitations. Bonjour is $hit, shouldn't be used on business networks to begin with, Fastlane is a gimmick, we generally avoid multicast on the WLAN. Still curious about the "high load" thought- given that CPU/memory can't be really seen.


"Bonjour is $hit"

I hear it is being renamed Liberty_Hi (it worked for French Fries)

Ban it and the screams of fanbois will be heard around the world . . .

In professional office suites and home offices, Bonjour and Chromecast are becoming common. When somebody is working late, a little music in the background often helps. 

The problem I have found is that it does not appear to feasible to put, say, ChromeCast players, on their own VLAN, even explicitly allowing the trusted devices on the secure VLAN access to the player VLAN, using the ports and protocols supplied by Google. I think the issue in this case is multicast.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

@DCooper That "common problem" documentation may explain a mystery that popped up yesterday. My MX100 security center said two retrospective malware detections occurred yesterday. The affected clients were two Meraki APs, not actual clients. So I can't figure out who the actual client is.

 

@wirednot Lee, I follow you on Twitter and you're immensely helpful in sharing your experience. Thanks.

Thanks for the kind words, CHAadmin. Are you syslogging the Meraki environment? If so, I may be able to help you.

No syslog server. Is there a cloud based syslog you recommend?

 

(P.S. Meraki needs to have cloud hosted syslogs)

Unfortunately, I don’t know about any cloud-hosted syslog servers. It is disappointing that the NAT records are not part of Meraki event logs- that’s a big black hole.

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