Auto VPN is a proprietary technology developed by Meraki that allows you to quickly and easily build VPN tunnels between Meraki MX devices at your separate network branches with just a few clicks.
Like Any other Site-to-Site VPN, Auto VPN has encryption, authentication and a key. The traffic is encrypted using an AES cipher. However, all of this is transparent to users and does not need to be (and cannot be) modified.
Auto VPN is a simple opt-in process. You can think of the dashboard as an existing VPN hub and spoke mesh topology environment, and every MX that has Auto VPN turned on is simply choosing to participate in that mesh.By default, all hubs contact all other hubs, and all spokes contact specified hubs.
What is Meraki AutoVPN?
If you’ve ever had to manually build site-to-site VPN tunnels between two devices, then AutoVPN appears to be black magic to the general observer. It’s absurdly simple to configure. So simple in fact, that it’s been the benchmark for the fastest VPN to provision in the industry for nearly a decade.
Click hub or spoke, pick your local networks or VLANs you want to advertise from the dropdown and click save. The cloud controller orchestrates all the rest. The best part is that’s just the foundation. With MX SD-WAN multipathing and app-based routing layered on top, it really has matured into a powerful, elegant software-defined WAN overlay solution for enterprise connectivity.
Components of AutoVPN
VPN Registry: This is the main server mechanism that allows Auto VPN to happen. It is a cloud service that is used to keep track of the contact information for all the MX devices participating in Auto VPN for an organization.
Hub: Hubs are devices in a VPN topology that service connectivity from a remote peer site (such as a spoke) to the hub and the hub to the remote peer site. Hubs also act as a gateway for remote peer sites to communicate with each other via the hub.
Peer: This refers to another MX within the same organization that a local MX will form or has formed a VPN tunnel to.
Contact: This is the public IP and the UDP port that the MX will communicate on for Auto VPN.
Process
Cisco Meraki devices, such as the MX Site-to-site VPN, or MR Teleworker VPN, the devices must first register with the Dashboard VPN registry.
In order to ensure connectivity, each Meraki node sends a keepalive message to the VPN Registry every 10 seconds. If more than 6 keepalives are not received by the registry, that node is marked as disconnected.
Both Meraki peers must be in communication with the VPN registry on UDP port 9350 / 9351 in order to get the correct information to form a valid VPN tunnel.
All the MXes (Hubs and Spoke) send a "Register Request Message" to the VPN Registry servers.
"Register Request Message" contains the public IP and the UDP port that the MX will communicate on for Auto VPN.
Now Registry server have the contact information of all the MXes in the organization
VPN registries send the Register Response messages to the MXs with the contact information of the peers the MXs should establish a tunnel with.
The cloud pushes a key to the MXs in their configuration which is used to establish an AES encrypted IPsec-like tunnel.
Local subnets specified by dashboard are exported/shared across VPN.
VPN routes are pushed from the dashboard to the MXs.
Finally, the dashboard will dynamically push VPN peer information (e.g., exported subnets, tunnel IP information) to each MX. Every MX stores this information in a separate routing table
A successful Auto VPN will have the below information.
Dashboard configuration
Enable Auto VPN by defining how the MX will communicate with the rest of the Auto VPN domain
Configure Full Tunnel or Split Tunnel.
Choose which subnets (local networks) to export over VPN.
AutoVPN + non-Meraki VPN Integration Considerations
Only subnets local to the MX can be advertised to the remote Non-Meraki VPN peer. The subnets specifically selected as Use VPN, yes on the Security appliance > Site-to-site VPN configuration page will be included as the local interesting traffic in the IPSec exchange.
Non-Meraki VPN routes are not advertised to OSPF or BGP peers.
Non-Meraki VPN remote subnets cannot overlap with existing local, static, or AutoVPN routes. Doing so generates a Dashboard validation error when trying to save the configuration.
Non-Meraki VPN routes are not advertised to AutoVPN peers.
Troubleshooting
If one Meraki device, is able to reach the VPN registry, but the intended peer MX is not, the tunnel will not form. Make sure that upstream firewalls are configured to allow traffic to the IP addresses (Help > Firewall info) and ports (UDP 9350/9351) for the VPN registry. It should also allow return traffic from established connections (this is allowed by default for stateful firewalls)
Both the hub and spoke will still be able to form the tunnel if the contact information remains the same, and they lost registry connectivity. Peer information will purge after a few hours causing the tunnel to be marked down.
VPN connections between Cisco Meraki devices, relies on a consistent IP address and port for both devices involved. Two VPN registry servers are used for redundancy, and both expect to see the device as available on the same public IP address and port.
However, some NAT devices (such as a firewall) will rewrite the source ports differently for each VPN registry server. Other NAT devices or load balancers will attempt to spread the connections to each VPN registry server across two different public IP addresses. Both of these cases will result in the VPN connection failing, and marking the NAT as unfriendly:
More information
Comments