Meraki

alemabrahao

That's a good plan, but remember to do it within a scheduled maintenance window to avoid headaches.

alemabrahao

Yo can call them. https://meraki.cisco.com/meraki-support/overview/

alemabrahao

In short, what you want to do will not work. Because when RADSec is enabled for any server on an SSID, the Meraki access point changes the transport mode for all RADIUS authentication to TCP instead of UDP.

alemabrahao

Another important detail: RadSec is TCP and regular Radius (port 1812) is UDP. So, although you can configure both on the same SSID, it's recommended that you use one or the other, not both.

alemabrahao

Strict Priority Order The servers will always be contacted in the order listed in Dashboard. In the example given, that ordering is 1,2,3. That means that server 1 is always contacted first and server 2 will only be contacted if server 1 cannot be reached. Similarly, server 3 will only be contacted if neither server 1 nor server 2 can be reached. https://documentation.meraki.com/Wireless/Design_and_Configure/Configuration_Guides/Encryption_and_Authentication/RADIUS_Failover_and_Retry_Details#:~:text=(see%20below).-,Retry%20Timing,An%20error%20packet%20is%20received.

alemabrahao

You asked if it was possible to configure it, and in fact it is, but whether it will actually work is another question. 😉

alemabrahao

Remember, the SSID will respect the server list from top to bottom, so while the server above is responding, nothing will be forwarded to the server below. This explains the behavior. Keep them on separate SSIDs and everything will be fine, or move everything to RadSec.

alemabrahao

It is possible to configure, but not recommended. If you must keep one server on UDP/1812, the safest configuration is place legacy RADIUS servers on a different SSID, or move all servers to RadSec if possible.

alemabrahao

You can configure both regular RADIUS (UDP/1812) and RADSec on the same SSID in Meraki, but not on the same server entry. Meraki | RADIUSaaS If you must keep one server on UDP/1812, the safest configuration is place legacy RADIUS servers on a different SSID, or move all servers to RadSec if possible.

alemabrahao

Yes, and the Meraki app (the second link) exists for that. Sorry, but I don't see the point in your request. Besides, there are APIs that allow you to develop your own app. https://developer.cisco.com/meraki/api-v1/get-device-camera-video-link/

alemabrahao

Look, I'm sorry, but I think the Vision portal is precisely for that purpose, isn't it? https://vision.meraki.com/ https://documentation.meraki.com/IoT/MV_-_Smart_Cameras/Operate_and_Maintain/Viewing_Video/Mobile_App_-_Camera_Experience

alemabrahao

Check the local status page on the switch to see what the problem is. https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Troubleshooting_and_Support/Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page If that doesn't solve the problem, try restoring the switches to their factory settings.

alemabrahao

One option is to configure the Meraki integrity check endpoint to be any reachable HTTP host, as long as traffic to it is routed through the IPsec tunnel.

alemabrahao

Meraki’s Primary/Secondary IPsec tunnel failover requires Layer‑7 HTTP health checks. This is explicitly stated in Cisco Meraki’s documentation: MX uses HTTP‑based Layer‑7 probes to verify tunnel health and failover status. Primary and Secondary IPsec VPN Tunnels - Cisco Meraki Documentation Netskope's IPsec guides do not mention any HTTP‑probe‑capable health check targets, only IP addresses and crypto requirements for the tunnels themselves. https://docs.netskope.com/en/netskope-ipsec-with-cisco-meraki-mx/

alemabrahao

AutoVPN Registry Communication (Control Plane)9350–9381, Is used to register public IP, NAT port, peer discovery. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/Meraki_Auto_VPN_-_Configuration_and_Troubleshooting IPsec Tunnel Traffic (Data Plane)32768–61000 (ephemeral, per-MX), is used for actual encrypted ESP-over-UDP between MX peers. Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers - Cisco Meraki Documentation Documentation is your best friend. 😉

alemabrahao

In Meraki AutoVPN, the inner IP header is fully encrypted and encapsulated inside an ESP packet. Although Meraki does not publish packet‑structure diagrams, their documentation confirms two essential facts: AutoVPN uses IPsec ESP for data‑plane encryption. The UDP ports below are used by Automatic NAT traversal. When peers are directly connected to the Internet with a public IP address and not protected by a transparent firewall or when peers are behind a firewall and NAT that allow all outbound traffic and does not perform load balancing, no further configuration is necessary on upstream security systems. In this case the tunnel should be established and all peers will show up as connected in Dashboard. However in the case that your Cisco Meraki peer resides behind a restrictive firewall the following connection types are required. To contact the VPN registry: Source UDP port range 32768-61000 Destination UDP port range 9350-9381 For IPsec tunneling: Source UDP port range 32768-61000 Destination UDP port range 32768-61000 meraki_whitepaper_autovpn.pdf

alemabrahao

I'm not an expert in the field, but I believe that combining the access point usage history (AP usageHistory) with the client's usage history seems to me the most accurate and reliable way to obtain information.

alemabrahao

There isn't a single Meraki API endpoint that produces the Usage data over time for the Summary Report. I believe the closest thing to what you need would be to manually aggregate multiple endpoints.

alemabrahao

I had already shared that same link you provided with him in another of his posts. 😅

alemabrahao

The access point is showing an error. What does the error suggest? Have you already contacted support?

alemabrahao

No, each person should have their own individual account, and you grant the necessary permissions according to what they need to access. https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/Managing_Dashboard_Access/Managing_Dashboard_Administrators_and_Permissions

alemabrahao

Don't you think reserving only 5 Mbps is too low? I believe that, depending on the number of users, this transfer rate is insufficient, especially if they are using video during the meeting. Have you tried increasing the limit or removing this restriction? Regarding the compatibility issue, there's not much we can do besides suggesting you update your browser or use a different one.

alemabrahao

Cisco.com accounts used for TAC cases, downloads, partner portals, etc, now enforce MFA for partners. This applies to logging in at id.cisco.com and related Cisco services. Cisco documentation confirms that MFA is handled within the Cisco.com identity profile itself and supports Duo/Google Authenticator. Meraki Dashboard accounts are separate identities unless you specifically configure one of these: Cisco SecureX Sign‑On uses Cisco identity SAML SSO using your own IdP

alemabrahao

The MX does not support source NAT, so it's not possible to have the client access the internet with a different IP address than the one configured on the WAN. As for WAN 3, it's a backup interface; that is, WAN 1 and WAN 2 remain active, and WAN 3 will only become active if one of the two active WANs fails. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Operate_and_Maintain/How-Tos/MultiWAN#MultiWAN_Backup_Uplink_(2_Active_.2B_1_Backup_link)_Feature

alemabrahao

One simple way I can think of is to limit the number of MAC addresses on the access point's uplink port by restricting it to one MAC address as a fixed active MAC address, and the action in case of violation being to shutdown. https://documentation.meraki.com/Switching/MS_-_Switches/Design_and_Configure/Configuration_Guides/Port_and_VLAN_Configuration/Switch_Ports#Port_configuration

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges