Troubleshoot Cisco Meraki AutoVPN Site-to-Site Connectivity

When a site-to-site flow fails, separate tunnel health from route advertisement, LAN routing, and firewall policy. This read-first runbook uses Cisco Meraki Dashboard pages and a controlled client test to narrow the fault. It does not change VPN configuration.

Record the path before changing a live VPN

Changing which subnets use VPN, outbound firewall rules, or uplink settings can affect an entire site. Start with read-only checks, record the source and destination subnets, and get the network owner’s approval before making a configuration change.

01

Define One Failing Flow

Scope

Record the source client and subnet, destination host and subnet, application or port, time of failure, and whether the same client can reach a local resource and the internet. Test one known destination in each direction if that is within your authorization.

Source site / subnet:
Destination site / subnet:
Test host and service:
Failure time and timezone:
Internet and local-LAN test results:

❯ Illustrative Output (Results Vary)

Keep the same source, destination, and test service through the checks that follow.

---

02

Check VPN Registry and Peer Status

Dashboard Read-Only

In the affected network, open Security & SD-WAN > Monitor > VPN status. Check the local appliance’s VPN registry state, NAT type, routing errors, and the specific remote peer. Repeat the check in the other network when you have access.

Record for both peers:
- VPN registry connectivity
- Peer / tunnel status
- NAT type or traversal warning
- Any overlapping-subnet or routing error

❯ Illustrative Output (Results Vary)

Classify the result: local registry reachability, one peer/tunnel, or a route/subnet issue.

Check primary WAN context

Cisco documents that the VPN Status page reports the primary WAN interface’s connection to the registry. If the primary WAN is down while another WAN is active, the page can still report no registry connectivity. Compare appliance uplink status and the affected peer before concluding all AutoVPN paths are down.

---

03

Correlate Events with the Failure Time

Event Log

Open Network-wide > Monitor > Event Log, select the security appliance events where the dashboard offers a device-type filter, and narrow the time range to the recorded failure. Review Meraki VPN and route-tracking events for both the local and remote networks.

Filter by the affected network and time window.
Record event type, peer, connectivity state, and event timestamp.
Compare local and remote event sequences.

❯ Illustrative Output (Results Vary)

Use event timestamps to align a tunnel or route change with the failed client test.

---

04

Verify Both Subnets Are Advertised

Route Check

On each endpoint network, review Security & SD-WAN > Configure > Site-to-site VPN. Confirm that the local subnet containing the client and the remote subnet containing the destination are each set to use VPN. Then open Security & SD-WAN > Monitor > Route table and check for the expected remote route and any overlapping or more-specific prefixes.

On both endpoint networks, record:
- Local networks included in site-to-site VPN
- The remote subnet and its expected VPN peer
- Any subnet overlap or routing error
- Whether the route table shows the expected route as active

❯ Illustrative Output (Results Vary)

The source and destination prefixes are unique, advertised by the intended peers, and present in the route table.

Do not toggle a subnet just to test it

The Use VPN setting changes traffic routing for that subnet. If it is disabled or incorrect, capture the current setting and route evidence, then plan a reviewed change with both site owners. Do not use a live production network as an unapproved test.

---

05

Check the LAN Route and Firewall Path

End-to-End Path

If the VPN peer is up and the route is present, verify that LAN clients send remote-subnet traffic to the Meraki appliance. Where another router or Layer 3 switch is the client gateway, check its route to the appliance. Review site-to-site outbound rules, local appliance policy, intervening firewalls, and the destination host firewall.

From an authorized test client:
1. Test the same application against a local destination.
2. Test the intended service at one remote host.
3. If permitted, compare a route trace with the expected gateway path.
4. Check the destination host's service and firewall logs at the same time.

❯ Illustrative Output (Results Vary)

Separate a VPN path failure from a missing LAN route, blocked service, or host firewall rule.

---

06

Summarize the Fault Domain and Verify Recovery

Close Out

Use the evidence to identify whether the issue is registry/NAT connectivity, a single peer, missing route advertisement, overlapping subnets, LAN routing, or filtering. Escalate to the appropriate uplink, firewall, LAN, or Meraki owner with the two networks, exact prefixes, timestamps, VPN status, route evidence, and test results. After an approved fix, repeat the same client flow and check both directions required by the application.

Outcome:
Evidence:
Owning team / approved change:
Post-change test and timestamp:

❯ Illustrative Output (Results Vary)

Close the incident only after the expected application flow succeeds and the route/tunnel state is stable.

Upstream references

See Cisco Meraki’s Auto VPN troubleshooting guide, VPN Status page reference, and Event Log guide for current Dashboard paths and device-specific details.