Meraki Security Appliance

Meraki Security Appliance (MX)

Overview

The Meraki MX is a cloud-managed security appliance combining routing, stateful firewall, SD-WAN, and Auto VPN. This skill covers the two curated MX capabilities: reviewing and updating the Layer 3 outbound firewall ruleset, and checking site-to-site VPN status. Firewall changes are high-impact -- the update tool replaces the entire ruleset, so read before you write.

Anti-triggers

• A firewall that is not a Meraki MX — these rules are MX L3 outbound only. A Fortinet, SonicWall, or Palo Alto ruleset is not reachable from this plugin at all; auvik-devices can tell you what the firewall is, not change it.
• Inbound port forwarding, content filtering, or L7 rules — the curated tools cover the L3 outbound list alone; everything else on the MX goes through meraki_raw_request, documented in meraki-api-patterns.
• Client VPN or a remote-access VPN user — meraki_appliance_vpn_status_get reports site-to-site Auto VPN peers only.
• A tunnel that is down because the appliance is — check the MX and its uplinks before diagnosing VPN config; use meraki-troubleshooting.

L3 Outbound Firewall

Rule Model

MX L3 outbound rules are an ordered list evaluated top-to-bottom; the first match wins. Each rule has:

There is always an implicit default allow rule at the bottom of the outbound list. Rules you configure sit above it.

Get Current Rules

meraki_appliance_firewall_l3_get

Parameters:

• network_id -- The MX network (required)

Example response:

{
  "rules": [
    {
      "comment": "Block outbound SMB to internet",
      "policy": "deny",
      "protocol": "tcp",
      "srcCidr": "any",
      "srcPort": "any",
      "destCidr": "any",
      "destPort": "445",
      "syslogEnabled": true
    },
    {
      "comment": "Default rule",
      "policy": "allow",
      "protocol": "any",
      "srcCidr": "any",
      "srcPort": "any",
      "destCidr": "any",
      "destPort": "any"
    }
  ]
}

Update Rules (High-Impact)

meraki_appliance_firewall_l3_update

Parameters:

• network_id -- The MX network (required)
• rules -- The complete ordered ruleset (required)

CRITICAL: The update replaces the entire ruleset. It is not additive. Any existing rule you omit is deleted. Always:

1. meraki_appliance_firewall_l3_get to fetch the current rules
2. Modify the list in place (add/remove/reorder)
3. Send the full modified list back
4. Do not include the implicit default rule unless the Dashboard shows it as editable

A mistake here can cut off a site's internet or open it up. Present a clear before/after diff and require explicit user confirmation before writing.

Reviewing for Overly-Permissive Rules

Flag rules that weaken the security posture:

• Any/any allow above the default -- policy: allow, protocol: any, srcCidr: any, destCidr: any, destPort: any. This is effectively "allow everything" and usually redundant or dangerous.
• Broad inbound-equivalent exposure -- allow rules to sensitive destination ports (3389 RDP, 22 SSH, 445 SMB, 23 Telnet) from any source.
• Missing comments -- unlabeled rules are unauditable; flag them for documentation.
• Disabled logging on deny rules -- syslogEnabled: false on security-relevant denies reduces visibility.
• Shadowed rules -- a broad allow above a more specific deny means the deny never matches.

Site-to-Site VPN Status

Auto VPN Model

Meraki Auto VPN builds IPsec tunnels between MX appliances in the same org automatically. An MX participates as a hub or spoke (or is disabled). The status endpoint reports peer connectivity and export/import of subnets.

Get VPN Status

meraki_appliance_vpn_status_get

Parameters:

• network_id -- The MX network (required)

Example response:

{
  "networkId": "L_123456789012345678",
  "networkName": "HQ",
  "deviceStatus": "online",
  "vpnMode": "hub",
  "exportedSubnets": [
    { "subnet": "192.168.1.0/24", "name": "HQ LAN" }
  ],
  "merakiVpnPeers": [
    { "networkId": "L_222", "networkName": "Branch-A", "reachability": "reachable" },
    { "networkId": "L_333", "networkName": "Branch-B", "reachability": "unreachable" }
  ],
  "thirdPartyVpnPeers": []
}

Interpreting VPN Status

• reachability: unreachable on a peer means the tunnel is down -- the two sites cannot route the exported subnets between them.
• A spoke that cannot reach its hub is isolated from the VPN mesh.
• Check deviceStatus first -- if the local MX is offline, every tunnel will read down and the real problem is the appliance/uplink, not VPN config.

Common Workflows

Firewall Rule Audit

1. Call meraki_appliance_firewall_l3_get for the network
2. Walk the ordered list; flag any/any allows, sensitive-port exposure, unlabeled and shadowed rules
3. Summarize findings with the rule index, the issue, and the risk
4. Recommend specific changes -- do not write unless asked and confirmed

Safe Firewall Change

1. meraki_appliance_firewall_l3_get and show the current rules
2. Propose the exact new ordered list with a before/after diff
3. Get explicit user confirmation
4. meraki_appliance_firewall_l3_update with the full modified ruleset
5. Re-get to verify the change landed as intended

VPN Health Check

1. Call meraki_appliance_vpn_status_get per MX network (or sweep across networks)
2. Confirm deviceStatus is online before trusting peer reachability
3. Flag any peer with reachability: unreachable
4. For hubs, confirm all expected spokes are reachable; for spokes, confirm the hub is reachable

Error Handling

400 on Firewall Update

Cause: Malformed rule (bad CIDR, invalid port range, unknown protocol) or missing required field Solution: Validate each rule against the schema; re-get to compare against a known-good shape

Empty / 404 Firewall or VPN Response

Cause: The network has no MX appliance, or the network ID is wrong Solution: Confirm the network's product types include appliance; verify the network ID

VPN Shows All Peers Down

Cause: The local MX is offline or its uplink failed -- not necessarily a VPN misconfiguration Solution: Check device and uplink status (see the troubleshooting skill) before diagnosing VPN config

Best Practices

• Always get the current firewall ruleset before any update -- the update replaces everything
• Present a before/after diff and require explicit confirmation for firewall changes
• Keep every rule commented so the ruleset stays auditable
• Flag any/any allows and sensitive-port exposure during reviews
• Enable syslog on security-relevant deny rules for visibility
• Verify MX deviceStatus is online before interpreting VPN peer reachability
• Treat firewall and VPN changes as change-controlled, high-impact operations

Related Skills

• api-patterns - Auth, read-only model, rate limiting
• devices - MX device status and uplinks
• troubleshooting - Uplink and connectivity live tools