AutoVPN tunnels not re-establishing after WAN drop

ITSDigital
Here to help

AutoVPN tunnels not re-establishing after WAN drop

We have an intermittent AutoVPN issue with our multi hub-to-spoke organisation.

 

Our hubs and spokes are all directly attached to DIA connections with public RIPE IPs with no upstream firewall. All hubs have fibre ethernet leased DIA connections. Spokes have a mixture of technologies: FTTC, FTTP and fibre ethernet. All spokes are connected to three hubs via full tunnel AutoVPN.

 

The recurring issue: after a short period of packet loss on the WAN side of a spoke - some or all of the AutoVPN tunnels do not re-establish by themselves. Clients and the MX itself on the spoke networks can reach the internet when the tunnels drop, the Meraki VPN registry stays contactable, but the tunnels do not always rebuild automatically.

 

This requires us to manually change the spoke's Site-to-Site VPN configuration to Off, save config, then set back to Spoke again before the tunnels will rebuild.

 

We see the issue occur when:
* Most common: the spoke MX WAN has an upstream NAT router (no firewall rules, NAT type friendly).
* Least common: the spoke MX WAN has an upstream Draytek 167 VDSL modem (PPPOE mode, no firewall, no NAT).

 

The frequency of the issue is every week when in NAT mode. Around a month or so in PPPOE modem mode.

 

We are using firmware MX 19.2.4 but have seen the issue on the 18.x release train.

 

Meraki support has been engaged with multiple times but have not been able to confirm a root cause, but were leaning towards it being a ISP issue. This issue has occurred on multiple ISPs, nothing is configured on the WAN/ISP side to inhibit NAT or VPNs. No carrier NAT or WAN firewalls. The issue also occurs if only one hub is connected via AutoVPN.

 

Has anyone else seen this kind of issue occur?

4 Replies 4
ITSDigital
Here to help

Here's a redacted event log of a site which had it occur today:

 

Time(GMT) Category Event type Details
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:38485, connectivity: true"
Nov 25, 2025 08:29 BGP BGP session established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 08:29 BGP BGP session established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 08:29 BGP BGP session established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:36415, connectivity: true"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:46946, connectivity: true"
Nov 25, 2025 08:29 Route tracking Route connection change "peer_type: l3_vpn, peer: [REDACTED_MAC], connection_status: connected"
Nov 25, 2025 08:29 Route tracking Route connection change "peer_type: l3_vpn, peer: [REDACTED_MAC], connection_status: connected"
Nov 25, 2025 08:29 Route tracking Route connection change "peer_type: l3_vpn, peer: [REDACTED_MAC], connection_status: connected"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:36415, connectivity: true"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:46946, connectivity: true"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:38485, connectivity: true"
Nov 25, 2025 08:29 Meraki VPN VPN tunnel "msg: FIPS mode disabled"
Nov 25, 2025 08:28 BGP BGP session no longer established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512, new_state: Close"
Nov 25, 2025 08:28 BGP BGP sent notification "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 02:00 Appliance status Primary uplink status change "uplink: 0"
Nov 25, 2025 02:00 Meraki VPN VPN registry connectivity change "vpn_type: site-to-site, connectivity: true"
Nov 25, 2025 02:00 Appliance status Primary uplink status change "uplink: 1"
Nov 25, 2025 02:00 Meraki VPN VPN registry connectivity change "vpn_type: site-to-site, connectivity: false"
Nov 25, 2025 01:59 BGP BGP session no longer established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512, new_state: Close"
Nov 25, 2025 01:59 BGP BGP sent notification "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 01:59 Route tracking Route connection change "peer_type: l3_vpn, peer: [REDACTED_MAC], connection_status: disconnected"
Nov 25, 2025 01:59 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:36415, connectivity: false"
Nov 25, 2025 01:59 BGP BGP session no longer established "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512, new_state: Close"
Nov 25, 2025 01:59 BGP BGP sent notification "peer_ip: [REDACTED_IP], local_as: 64512, remote_as: 64512"
Nov 25, 2025 01:59 Route tracking Route connection change "peer_type: l3_vpn, peer: [REDACTED_MAC], connection_status: disconnected"
Nov 25, 2025 01:59 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:46946, connectivity: false"
Nov 25, 2025 01:59 Meraki VPN VPN tunnel connectivity change "vpn_type: site-to-site, peer_contact: [REDACTED_IP]:38485, connectivity: false"

alemabrahao
Kind of a big deal
Kind of a big deal

Have you already opened a support case?

This isn't very common, since auto VPN is extremely simple to configure.

Unless you have another firewall behind the MX, I don't see any other possibility besides a bug.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
GIdenJoe
Kind of a big deal
Kind of a big deal

AutoVPN tunnels should always come back up on their own.
The only reasons they would fail if you have a NAT type unfriendly or a firewall in front (even if that firewall is an ISP doing this).

Any other reason should be put into a support case.

PhilipDAth
Kind of a big deal
Kind of a big deal

Are you running a current stable or better firmware?

 

Do your hubs have the public IP addresses directly on their WAN interfaces, or are they running through NAT?

Get notified when there are additional replies to this discussion.