Just FYI, if a Guest User exists in the Client VPN, the following error occurs. > The server encountered an SSO error. Please contact your network administrator for assistance. > > For reference, your login was at Oct 02 06:55:55 UTC from #.#.#.#.   Please consider this specification as well when implementing SSO.   The relevant menu item is "User Management" section from "Security & SD-WAN > Client VPN". ... View more

If the user already exists as a Non-SAML User in Meraki Dashboard, "true" will be displayed. You should first check the SSO log. Go to "Organization > Administrators" and display "SAML Login History".   For example, the log will appear as follows   Found existing non-SAML user with email USERNAME@domain.test ... View more

> I had restarted the branch MX to ensure that the tunnel was re-established and still working with the setup, which it was (unless you mean restart the VMX?)   It was meant to restart vMX (Virutal MX).     > My understanding of what was happening was the static route on the VMX does not go active, and is ignored in VMX routing lookups, and all VMX traffic (except traffic to branch sites) is sent out the default route.   Yes, if the route is inactive with Static Route Tracking, I think that would be the behavior. Just FYI, topologies that accommodate MPLS on LAN ports take advantage of this behavior.   Integrating an MPLS Connection on the MX LAN - Cisco Meraki https://documentation.meraki.com/MX/Networks_and_Routing/Integrating_an_MPLS_Connection_on_the_MX_LAN   > So the static route is always inactive, but always advertises the Azure subnets to branch sites.   This is expected behavior. Even if Static Route Tracking is Inactive, routes are ALWAYS advertised to the Auto VPN Peer. Within the SD-WAN Fabric, Routed Mode cannot have duplicate routes. This eliminates the need to track status changes and reroute routes. I have previously contacted support about this behavior. If you are forced to use Full Tunnel & Limited NAT mode, there is a Local Internet Breakout feature as a mitigation measure. It is only a mitigation measure...   VPN Full-Tunnel Exclusion (Application and IP/URL Based Local Internet Breakout) - Cisco Meraki https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout)   ... View more

I did not find sufficient information in the documentation, so I previously contacted support to confirm the specifications. At the time I was also confused.   > -I have managed to set this up as split tunnel, by creating a static route to the subnets in Azure that I want my branch sites to reach.   I had never tried this method. It feels like a tricky workaround.   As a prerequisite, the instance must be restarted to reflect the vMX settings. Static Route is installed statically from Meraki Cloud to other MXs, so it is reflected without restarting. I am wondering if it will work after rebooting.   For your information, I will share a case study that I know of. If "Subnet (e.g. 192.168.128.0/24)"" setting is configured when VPN mode is Enable, the route will be publicized to other MXs without rebooting. This is because Auto VPN Route is installed statically from Meraki Cloud to other MXs. Therefore, the communication may appear to be working without problems. In other words, the Split Tunnel appears to be working. But, after rebooting, the route to "Subnet (e.g. 192.168.128.0/24)" becomes equivalent to Null0 and communication is no longer possible.   Regardless of the mode of vMX, I don't think it is expected to communicate from the Azure subnet to the Internet via vMX.   It is not possible with One-Armed Concentrator, at least not because it is not source NATed.   Since communication from the Public Cloud side to the Branch side is not possible in Limited NAT mode, it is assumed that communication to the Internet side is also not possible. It is similar to a typical NAT Router that does not allow WAN to LAN communication. (Unless you are setting up Static NAT, etc.) In the case of your requirements, though, it is WAN to WAN (Uplink to Uplink). Perhaps a dedicated Firewall product would be suitable.   Previously, changing vMX to Limtied NAT mode required contacting support. (Previously, The vMX "Addressing & VLANs" configuration menu did not appear.)) However, since the vMX mode setting screen now appears, I think it was matched with the default mode of MX. Whether it is appropriate for the customer or not. That is my guess. ... View more

The Limited NAT mode setting is special. I am explaining the components step by step.   vMX has only one NIC, regardless of mode. Communication via vMX to another segment is routed according to Underlay's default route. (Uplink's default route) Therefore, Static Route settings are not required.   Also, from other MXs, a default route must be set up to the vMX. (Full Tunnel) This is due to the special LAN Config settings in Limited NAT mode.   The LAN Config settings are specified as follows   [LAN Config (Limited NAT mode)] * MX IP: Specify the IP address of the vMX Uplink. (x.x.x.68)   MX IP is used by Source NAT.   * Subnet: Specifies the subnet to which the vMX belongs. (x.x.x.64/28)   The specified subnet will be unreachable. I think it is equivalent to Null0.   It is a required setting, so there is no choice but to set it.   Therefore, specify the subnet to which the vMX belongs and make it a dedicated segment for vMX only.   * VPN mode: Enblaed or Disabled   Either is acceptable.   This setting is virtually meaningless because the vMX cannot communicate to the subnet to which it belongs.   Please note that DC-DC Failover redundancy is not available in Limited NAT mode. ... View more

SSIDを掴んだ直後付近のリダイレクト処理だと、Meraki MR側はSplash pageの設定が関与してそうです。   "msftconnecttest.com -> msn.com" へのリダイレクト処理の発端は、 下記のドキュメントを見るとNCSI関連の処理にあたるように見えます。   コンピューターが企業ネットワークまたはパブリック ネットワークに接続すると、Internet Explorer または Edge ウィンドウが開きます - Windows Client | Microsoft Learn https://learn.microsoft.com/ja-jp/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network > プロキシ サーバーを使用してインターネットに接続するネットワークに接続する場合や、ネットワーク制限によって NCSI がアクティブなプローブ プロセスを完了できない場合など、Windows は既定のブラウザーで MSN ポータル ページを開きます。 > コンピューター上のネットワーク トレースを分析すると、それに対する http://www.msftconnecttest.com/redirect HTTP 接続が表示され、その後に MSN ポータルへの接続が表示されます。 Windows では、パッシブ プローブ プロセスの利点のためにこのページが開きます。 ページが読み込まれると、NCSI はコンピューターにインターネット アクセス権があると結論付けます。 > 異なるプローブが失敗してから成功すると、ネットワーク状態アラートが表示され、消えます。   Splash pageの設定があるとネットワーク接続を制限するので http://www.msftconnecttest.com/redirect に接続しに行って当該事象になっている可能性があるかなと。 まずはメニュー: "Wireless > Access control" で該当SSIDの設定が現状どうなっているか確認されてみるのが良いかなと存じます。 また、下記のトピックにて同様にリダイレクトされる事象の方が居たようです。   Getting the splash page to load on a Windows device - The Meraki Community https://community.meraki.com/t5/Wireless-LAN/Getting-the-splash-page-to-load-on-a-Windows-device/m-p/30445/thread-id/4795   ... View more

From what you say, it seems to me that there is no need to stick to Limited NAT mode.   It would be simple to configure vMX as One-Armed Concentrator [Passthrough or VPN Concentrator Mode] and advertise the subnet in Azure's vMX. The Local Networks setting can advertise specified subnets.   Overlay (on the Auto VPN tunnel) access control can be configured with the "site-to-site outbound firewall", which also allows One-Way communication (Branch -> Azure) can be allowed. ... View more

>  basically we are building autovpn to vmx and to access services in azure.    The vMX in Limited NAT mode performs Source NAT and hides the Branch's address. This may be a problem if you want to identify the user (Real IP address) on the Azure side.   In Limited NAT mode, communication from Azure to Branch is not possible because the branch's address is hidden by NAT. If it is a one-way communication (Branch -> Azure) like Shared Service, that restriction would not be a problem. ... View more

Meraki vMX's Limited NAT mode has only one Uplink.   Communication from the branch MX to the vMX "LAN Config > subnet" is absorbed by the vMX. Therefore, in Limited NAT mode, Full Tunnel must be configured from the branch MX to the vMX. Also, vMX must be deployed in a separate segment. My assumption is that the "LAN Config > subnet" setting may have been installed as Connected in the Routing table. (Blackhole)   A reboot is required after changing the settings. If not rebooted, the system may operate halfway.   Equivalent to Routed Mode of MX, DC-DC Failover topology is not possible in Limited NAT mode. ... View more

The behavior of the Meraki Dashboard has recently changed.   New Dashboard Security Features - The Meraki Community https://community.meraki.com/t5/Dashboard-Administration/New-Dashboard-Security-Features/m-p/177590/thread-id/6138 > Multi-Factor Authentication > As always, we advise that you enable MFA for an extra layer of security.   Authentication Enhancements and New Dashboard Security Features - Cisco Meraki https://documentation.meraki.com/General_Administration/Other_Topics/Authentication_Enhancements_and_New_Dashboard_Security_Features > Last updated: Dec 6, 202 ... View more

It is not Group Policy, but when 10,000 Organizations were created, the Web UI response was slow, as it should be. In the case of Group Policy, I am also concerned about the impact on Meraki devices. ... View more

1. What is the Mode of vMX? I was curious because the default vMX mode has recently changed.   vMX Setup Guide for Amazon Web Services (AWS) - Cisco Meraki https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Amazon_Web_Services_(AWS) > Change in default behaviour > > All new vMXens deployed post October, 31, 2022 will be deployed in Routed/NAT Mode Concentrator by default, existing vMX deployments will not be effected. If you wish to use the vMX in passthrough mode, please change the deployment settings to Passthrough or VPN Concentrator mode from the Security& SD-WAN > Configure > Addressing & VLANs page.   2. Have you set up a Route Table for return traffic on your AWS VPC? When configured in Limited NAT mode, only communication from the corporate LAN to the Windows Server on AWS is possible without setting a return route. Conversely, the AWS side will not be able to communicate with the corporate LAN. The reason is that in Limited NAT mode, addresses on the corporate LAN side are hidden by the source NAT. ... View more

* "Login IP range" is only applicable to Non-SAML User (Meraki Dashboard Account). * "Login IP range" does not apply to SAML User (SSO User).   Therefore, control it on the IdP side if necessary.   Organization Settings - Cisco Meraki https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Organization_Menu/Organization_Settings > Note: Security Settings do not apply to SAML Administrator accounts. ... View more

Devices can be registered in a new Organization by removing them from the inventory of an existing Organization.     Please refer to the following document for information on how to transfer licenses.   ** Co-Term ** How to do a License Transfer in Cotermination - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/How_to_do_a_License_Transfer_in_Cotermination   ** PDL ** Meraki Per-Device Licensing - Configuration - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overview/Meraki_Per-Device_Licensing_-_Configuration#Moving_Licenses_and_Devices     Please refer to the following document for information on how to clone from an existing organization   Cloning Networks and Organizations in Dashboard - Cisco Meraki https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Cloning_Networks_and_Organizations_in_Dashboard#Cloning_Organizations   ... View more

FYI   Previously, I have enabled NAT Mode [Routed Mode / NAT Mode Concentrator / Limited NAT mode] on Meraki vMX for verification purposes, but the configuration methods and constraints are complex.   * Originally, NAT Mode could not be selected without requesting support.   * Redundancy is limited in NAT Mode because it cannot be a DC-DC Failover topology.   * Since address translation is performed in NAT Mode, the Public Cloud side cannot connect to the Branch side.   This is because the Uplink of vMX is equivalent to WAN1 due to NAT Mode.   The behavior is similar to the general inability to connect from a WAN (Untrust) to a LAN (Trust).   * LAN side settings are special.   LAN setting: Single LAN   MX IP: MX's IP Address   Subnet: Subnet to which vMX belongs     CAUTION: Communication to the specified subnet will be unavailable.                     Therefore, vMX should belong to a dedicated subnet for each instance.                     Because of this characteristics, either VPN mode setting is acceptable.     A reboot is required for the settings to take effect.   * The Full Tunnel (IPv4 default route) setting is required because the VPN mode setting is practically meaningless.   ... View more

It is very helpful to know easily what's new! I look forward to it every month. ... View more

@Ryan_Miles  Thanks for your quick response! ... View more

Meraki MS intercepts the DNS communication and returns its own IP address (1.1.1.100) if it is "switch.meraki.com". It could be a problem with the client's DNS settings, so I suggest trying with IP addresses (1.1.1.100) to break down a problem.   Using the Cisco Meraki Device Local Status Page - Cisco Meraki https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page > MS - 1.1.1.100 > In order to access this address, configure a device with the following IP settings, and then browse the address in a web browser. > IP address: 1.1.1.99 > Subnet mask: 255.255.255.0 ... View more

I will share supplemental information.   The documentation does not indicate that management communication is always through Uplink. However, as far as I have previously verified, when uplink is down, management communication is lost.   MX Routing Behavior - Cisco Meraki https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#Behavior_of_Management_Traffic ref. Behavior of Management Traffic   > The following services/tools will specifically adhere to the route priority and not necessarily ingress or egress the primary WAN/Internet uplink: > > Advanced Malware Protection registration > Meraki Cloud Authentication > Meraki Cloud Communication on TCP ports 80,443 and 7734 > Ping and Dashboard Throughput Live Tools > List Updates for the following services: Content Filtering, IDS/IPS Rule Updates and Geo-IP Lists for Layer 7 Country-Based Firewall rules ... View more

Memo: Microsoft's official announcement about Public IP SKU   Upgrade to Standard SKU public IP addresses in Azure by 30 September 2025—Basic SKU will be retired | Azure updates | Microsoft Azure https://azure.microsoft.com/en-us/updates/upgrade-to-standard-sku-public-ip-addresses-in-azure-by-30-september-2025-basic-sku-will-be-retired/ ... View more

Could Meraki MX resolve that FQDN?   I could not reproduce this on the Meraki MX67W (MX 16.16) in my environment.     Web App Health Target: http://www.example.com/ Since Meraki MX intercepts DNS communications, I was wondering if internal DNS would conflict with Meraki Insight's functionality. ... View more

I will share the latest info. The documentation now clearly states that LACP and Link Aggregation are not supported on Meraki MX.   MX Layer 2 Functionality - Cisco Meraki https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality > LACP & Link Aggregation > The MX does not run LACP or any link aggregation protocols. Connecting aggregated ports to the LAN of the MX is not supported; all connected ports should be un-aggregated. If multiple ports are connected to the MX from a single switch for redundancy, it is highly recommended that you run STP on that switch, to ensure that one of the redundant ports is safely put into a blocking state. ... View more