Skip to main content
Cisco Meraki Documentation

Configuring Site-to-site VPN between MX Appliances in Different Organizations

All MX security appliances within the same organization will be able to use our AutoVPN feature to establish a Site-to-site VPN between themselves. However, if two MX Security Appliances are in separate organizations, they will not be able to set up an automatic VPN. They must be configured as if they were non-Meraki peers.

This article outlines the basic configuration steps necessary to establish a site-to-site VPN tunnel between MX devices in different organizations.

Third-party VPN Configuration

Setting up a VPN tunnel between MXes in different orgs requires the use of the third-party VPN section of the MX Dashboard. This can be found under Security & SD-WAN > Configure > Site-to-site VPN > Non-Meraki VPN peers.

In both organizations, click the "Add a peer" link. Fill out this entry as if the other MX were a 3rd party device, where each field should be configured as follows:

  • Name - Name of the remote peer (cosmetic).
  • Public IP - The public IP address from which the remote MX can be contacted. This can be found on the remote MX in Dashboard under Security & SD-WAN > Monitor > Appliance status > Uplink > Configuration > General > Public IP:
    uplink IP info.PNG
  • Private subnets - All subnets on the remote peer that will be participating in the VPN, in CIDR notation (e.g. Can be found on the remote MX in Dashboard under Security & SD-WAN > Configure > Addressing & VLANs.
  • IPsec policies - This should be kept default on both sides to avoid a mismatch. If a custom IPsec policy is configured for this tunnel on either peer, they must match exactly.
  • Preshared secret - A custom passphrase for encryption purposes. Must match exactly on both MXes.
  • Availability - Determines which MXes in the organization will be communicating with this peer. By default, all devices in an organization will establish tunnels with a third-party peer, however network tags can be used to limit these connections to a few networks.

This process would need to be repeated for each remote/local MX pair as desired. The image below shows an example of an MX to MX VPN connection when the devices are in different Organizations:

non-meraki peer example.PNG


Additional Considerations

Since this VPN tunnel is functionally the same as a tunnel to a third-party peer, the same restrictions and caveats apply, including the following notable caveats:

  • Limited visibility on the VPN Status Page.
  • In order to bring the tunnel up, you may need to generate interesting traffic which can be done by initiating a ping to an IP address in the remote subnet.

Additional Resources

For more information about site-to-site VPN tunnels and troubleshooting:

  • Was this article helpful?