I completely agree with your points. The lack of rule ordering, limited default deny options, and no proper destination scoping make org-wide group policies hard to use in anything beyond the simplest designs. Your proposed improvements would make them far more practical at scale. ... View more

Thanks for the quick reply! That’s exactly the endpoint I’ve been using    GET /organizations/{organizationId}/appliance/dns/local/profiles/assignments and then attempting POST /organizations/{organizationId}/appliance/dns/local/profiles/assignments/bulkDelete The problem is: the GET call isn’t returning any assignments for the profile, even though the DELETE call for the profile itself fails with “Networks are currently assigned to the profile”. So the API seems to know it’s assigned somewhere, but the assignments query comes back empty. Have you (or anyone else here) seen this mismatch? Could this be a bug in how assignments are being surfaced in the API? ... View more

Your understanding is correct. If both MX WAN ports are on the same L2 from the ISP and the /29 is delivered on the wire, assigning VIP (.4) plus additional public IPs (.5, .6) works: VIP handles AutoVPN and Client VPN without interruption, while DNAT rules against .5/.6 float seamlessly during warm-spare failover.   Just add the additional IPs under Security & SD-WAN > Configure > Firewall, set up your DNAT rules, and point all VPN traffic at the VIP.   Refer to the Meraki Documentation: https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX   https://meraki.cisco.com/blog/2014/08/1many-nat-for-meraki-mx/     ... View more

Short answer: Yes. You can use 1.1.1.5 and 1.1.1.6 for DNAT (1:1 or 1:Many) and they will fail over cleanly between the MXs as long as they’re on the same WAN segment as your VIP and your ISP/L3 upstream delivers that /29 on the wire. What this means in practice Your setup: MX1: 1.1.1.2/29 MX2: 1.1.1.3/29 VIP: 1.1.1.4/29 Free: 1.1.1.5, 1.1.1.6 (usable) Presumed: 1.1.1.1 = ISP gateway, .0 network, .7 broadcast (not usable) Failover behavior: The active MX will ARP for the VIP and any DNAT public IPs you configure on that uplink. On failure, ARP ownership moves to the spare—so inbound to .5/.6 keeps working without DNS changes.     How to configure (Meraki Dashboard) Confirm both MX WAN ports are on the same L2 segment from the ISP, using the same /29. Enable VIP (which you’ve done) under Security & SD-WAN → Appliance status → Uplink → Use virtual uplink IPs. Add the extra public IPs to the uplink that will host the NAT: Security & SD-WAN → Appliance status → Uplink → Additional public IPs (WAN1 or WAN2 as appropriate). Add 1.1.1.5 and 1.1.1.6. Create DNAT rules: 1:1 NAT: Security & SD-WAN → Firewall → 1:1 NAT; set Public IP = 1.1.1.5 (or .6), map to the internal host. 1:Many NAT / Port forwards: Add rules and select the added public IP in “Public IP”.     Key caveats (don’t skip) Those extra IPs must be routed/advertised by the ISP on the same access circuit. If the ISP is doing any upstream NAT or filtering ARP, tell them you’ll be ARP-owning .5/.6 on that interface. Additional public IPs are per uplink. Only add .5/.6 on the uplink whose subnet they belong to (here, WAN1 if that’s where the /29 lives). Client VPN & AutoVPN can keep using the VIP (.4). DNAT can use .5/.6. Mixing is fine. Don’t reuse .1 (likely ISP gateway) or .0/.7. If all of the above checks out, you’re good: 1.1.1.5 and 1.1.1.6 are ideal for DNAT with seamless HA. ... View more

You’re correct! per IEEE 802.11, association status codes 27–31 are reserved and have no standard definition. Vendors can (and do) use them internally for their own reasons, which is why you won’t find a public explanation in the spec. In your case: Failed to associate -  auth_mode='wpa2-psk' 11k='1' 11v='1' error_code='30' radio='1' vap='0' channel='104' rssi='40'      Code 30 is likely a vendor-specific catch-all for a capability or policy mismatch, often seen with: Clients that don’t fully support 802.11k/v roaming DFS channels (e.g. ch.104) where the client doesn’t pass DFS capability checks Firmware policy blocks before completing RSN authentication   How to narrow it down: Check client capabilities — verify the device’s 5 GHz support, DFS support, and 11k/11v compatibility. Disable 11k/11v temporarily to see if the problem disappears. Test on a non-DFS channel (36, 40, 44, 48) to rule out DFS-related association failures. Check AP firmware/changelog — some vendor firmware releases note fixes for “reserved association code” handling. Enable verbose client debug logging on the AP/controller to capture the exact step of failure (before/after RSN handshake). If reproducible with specific client models, check vendor bug databases — reserved codes often show up in known interoperability bugs. Unfortunately, since it’s a reserved code, the real meaning is implementation-specific and not documented outside of vendor support channels.   Bottom line: Error code 30 isn’t in the standard; it’s vendor-specific. The only way to get a definitive definition is to check with your Meraki TAC/support, providing them with a wireless packet capture of the failure. They can map code 30 to their internal reason codes.   ... View more

if you’re running warm spare without a Virtual IP (VIP), failover will work for outbound, but inbound and VPN traffic will behave differently: What happens now without a VIP Auto VPN (Meraki2Meraki): Will automatically re-establish to the secondary’s public IP when failover happens. There’s a short outage during tunnel re-negotiation. Non-Meraki VPN peers: The remote side must be able to connect to both WAN IPs (primary and secondary). If it only dials the primary IP, failover will break the tunnel until you change it. Client VPN (RA VPN): The public endpoint changes to the secondary MX’s IP on failover. If users connect via the Meraki DDNS hostname, it updates automatically; if they use a fixed IP, they’ll need to switch to the secondary. DNAT/Port Forwards: Inbound traffic will only work to the active MX’s public IP. If your DNS still points to the primary IP after failover, inbound will fail until you update it.   Why??? Without a VIP, the active MX’s public IP changes during failover. Anything pointing to the old IP will stop working until you re-point it.   How to fix it If both MX uplinks are on the same ISP subnet: Go to Security & SD-WAN → Appliance Status → Uplink configuration. Enable Use virtual uplink IPs. Assign an unused public IP from the same /29 as the VIP. Update your DNS/VPN peers to point to the VIP. This way, Auto VPN, Client VPN, and DNAT will all use the same IP before and after failover — no DNS changes needed. If your uplinks are on different ISP subnets and you can’t use VIP: Use an FQDN for VPN and inbound services with a low TTL. Configure both MX public IPs on remote VPN peers. Automate DNS failover to the secondary IP when the primary is down.   ... View more

Yes you can do this directly in Meraki without an external firewall. Go to Security & SD-WAN → Site-to-site VPN in Dashboard. In the VPN settings section, look at the VPN firewall rules (sometimes labeled “VPN firewall” or “Custom rules” under “Site-to-site VPN”). These rules control traffic that traverses the AutoVPN fabric. You can explicitly deny branch-to-branch subnets while allowing branch-to-DC traffic. For example: Deny: Source = Branch subnet(s), Destination = other Branch subnet(s) Allow: Source = Branch subnet(s), Destination = DC subnet(s)   Since these rules are enforced in the VPN overlay, the block happens before traffic can pass between branches, and you don’t need to touch the traditional firewall at the hub. ... View more

Just to confirm is 1.1.1.2/29 and 1.1.1.3/29 on the same WAN segment from the same ISP, and is the 1.1.1.1/29 network shared between both MXs?   If so, you can assign a WAN Virtual IP to make Client VPN and DNAT failover seamless. If they’re on different upstream networks, a VIP won’t be possible and you’ll need to rely on DDNS/DNS changes. ... View more

In the Meraki “Sponsored Guest” flow, the sponsor can only approve or deny requests  the access duration is a global setting configured on the SSID splash page by a dashboard admin. There’s no built-in option for the sponsor to set a custom expiry per guest at approval time. If you need flexible, per-guest durations, you’d have to move away from the native Meraki sponsored portal and use an external captive portal with RADIUS authentication. In that model, the portal can present the sponsor with a duration selector and then pass the chosen value back as a RADIUS Session-Timeout attribute (optionally with Change-of-Authorization support) to enforce it. Alternatives inside Meraki without custom development are limited to: Creating multiple SSIDs with different fixed expiry times, or Pre-provisioning guest accounts with different expiries for the sponsor to hand out. Bottom line: native Meraki sponsored guest does not support sponsor-defined durations you’ll need either an external portal or a workaround with predefined durations.   ... View more