Meraki

Nash · ‎Aug 21 2019

1) You can send syslogs to a syslog server. Here's an example of the supported events: https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Syslog_Event_Types_and_Log_Samples 2) When you say mac-based authentication, do you mean 802.1x on the ports? If so, no, not on an MX84. (https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X)) 3) What do you want to authenticate? Client VPN supports RADIUS or ActiveDirectory. (I prefer RADIUS via NPS in an AD environment... simpler.) Or you can use SAML for authenticating administrators.

Nash · ‎Aug 19 2019

If I understand correctly, this is an external attacker trying to open an RDP connection over a non-standard port. It relies upon you having allowed Internet traffic to a Windows machine, such as through port forwarding or NATting. If you've got RDP enabled on a public-facing device, you should disable that right now, in my opinion. Find another way to remotely manage that device. Lot of folks think RDP on a non-standard port is "safe" and uh... no. This is why it's not.

Nash · ‎Aug 19 2019

I would give my eye teeth for these end points, but we don't have them right now. I'm not sure if we ever will, but I am very hopeful. Are you in a position where you could use RADIUS instead for the client VPN? That can simplify user management, especially if you're working with ActiveDirectory users.

Nash · ‎Aug 19 2019

@BBDave wrote: Is the management port just a console port like you have on a switch? for connecting directly I wonder. On some models of MX, yes. The 60 line doesn't have management ports, but the larger rack-mountable units should. It's for accessing the local status page.

Nash · ‎Aug 16 2019

We're all setup as full org admins for API reasons, and use Google Auth for 2FA.

Nash · ‎Aug 15 2019

So MS acts a bit like Portfast, just with less risk of loop and a bit more intelligence.

Nash · ‎Aug 14 2019

Note that if you're in the process of setting up new equipment for a client, their org will show red due to offline equipment at some point. If there's a delay between setup and install, that'll make it less useful. Have you thought about webhooks? https://documentation.meraki.com/zGeneral_Administration/Other_Topics/Webhooks

Nash · ‎Aug 13 2019

We primarily use the baked-in Dashboard alerts, fed into ConnectWise tickets. For clients with mixed network stacks, we'll ensure ICMP internally is allowed and also use Auvik. We accept that the SNMP info that Meraki gives is the SNMP info it gives. While it would be nice to have things like cpu/mem usage, and device's own idea of its uptime, that's not something that Meraki offers at this time.

Nash · ‎Aug 9 2019

If you had an MX, this would be real easy to do. Just connect each link to your WAN interfaces and be done with it. Unfortunately, an MS won't do this. I'm looking at the routing setup on an MS350. There's no option to setup any kind of "ip sla"-type link monitoring. You can get that on an MX, but not a Meraki switch.

Nash · ‎Aug 8 2019

I can't imagine 4000 iPads. Your MDM setup must be impressive.

Nash · ‎Aug 7 2019

Yeah no, definitely don't leave a testing SSID up for any longer than you're using it. Phillip may be onto something with regards to the older protocols. The Honeywells I've dealt with (CK75) are crotchety and the wifi NIC really doesn't support anything modernish.

Nash · ‎Aug 7 2019

Will the scanners connect to a test SSID on the Meraki AP that uses WPA2-PSK? If not, will they connect to an open SSID? Obviously, lock this SSID down so it does not have LAN access.

Nash · ‎Aug 7 2019

No, I totally use Google. Usually when I want to check both the official documentation and the forum at once, and see if maybe Reddit or Server Fault has something useful to say. Usually the answer is in the official docs or here, though. I need to experiment with the baked-in forum search.

Nash · ‎Aug 6 2019

I really think you need to explore port-security settings on your switches and disabling unused switchports. The MX can only block traffic that flows through itself. Internal switch traffic, for instance, doesn't go through the MX. So a device that connects to one of your switches will still be able to chat with at least some devices on your LAN. If you want to deny LAN access to unapproved wired devices, you're going to have to approach this from multiple angles.

Nash · ‎Aug 6 2019

@Seshu has it right with the group policy, from the MX point of view. I do want to point out that if your goal is also to deny LAN access to wired devices, you're going to have to take measures on your switches. I.E. turn ports off unless you know they're going to be used, setup port security, all them goodies.

Nash · ‎Aug 6 2019

Do all of your devices connect to your MX64 directly, or do you have switches involved?

Nash · ‎Aug 2 2019

Oh, I feel your pain. Long live the testing SSID. My problem child clients have one permanently configured but turned off. Good luck.

Nash · ‎Aug 1 2019

@Leeham Congratulations, friend!

Nash · ‎Aug 1 2019

Okay, if you're using Meraki DHCP (i.e. the AP hands out something in the 10.0.0.0/8 space and NATs to itself) and you're not seeing the client on any APs... I'd really go for having this user have their device around, while you're watching to see what happens when they try to connect.

Nash · ‎Aug 1 2019

Where's your source of DHCP for your wifi? If it's not Meraki DHCP, you might be able to check the DHCP server for that mac address and get a searchable IP. Or it's possible that the device just isn't showing up as a client at all, for some reason. In that case, you'll need to have them connect at a time when you're available to troubleshoot.

Nash · ‎Aug 1 2019

Look up that device under Network->Clients and click into it. What do you see under Policy? Is it set to Blocked, or placed in a Group Policy that would block it?

Nash · ‎Jul 31 2019

Your VPN traffic won't be sent unencrypted. It'll be encapsulated within the IPSEC tunnel. Setting encryption to optional has to do with how the user name/password is transmitted. Win10 does not support -Encryption Required for PAP or CHAP. So it assumes that -Encryption Required is correct, and will eventually change your password protocol to EAP and MS-CHAPv2. Then you get tickets about "broken" VPN connections. When you created the account with PowerShell using -Encryption Required, you should have seen an error like this: Add-VpnConnection -name Testbob -ServerAddress testbob.com -TunnelType L2tp -EncryptionLevel Required -L2tpPsk testbob -AuthenticationMethod pap Add-VpnConnection : The current encryption selection requires EAP or MS-CHAPv2 logon security methods. PAP and CHAP do not support Encryption settings 'Required' or 'Maximum'. : The parameter is incorrect. At line:1 char:1 + Add-VpnConnection -name Testbob -ServerAddress testbob.com -TunnelTyp ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (AuthenticationMethod:root/Microsoft/...S_VpnConnection) [Add-VpnConnec tion], CimException + FullyQualifiedErrorId : WIN32 87,Add-VpnConnection

Nash · ‎Jul 31 2019

Do be aware that if you change to require, it's going to change your password protocol on you at some point. Windows 10 doesn't really support required encryption when using the PAP protocol. This can cause the VPN connection to "break" with no warning, especially after running updates.

Nash · ‎Jul 30 2019

I did not realize wishes were routed that way. It makes sense in retrospect. Thanks for the heads up, @DavidLowe!

Nash · ‎Jul 30 2019

What does a traceroute look like from Site A's public IP to Site B's public IP, and vice versa? Is there a hop in the route that goes slow?

About Nash

Nash

Nash King

Community Record

Badges