The MX Security Appliance provides the ability to configure VPN tunnels to non-Meraki devices. This article describes non-Meraki VPN considerations, required configuration settings, and how to troubleshoot MX to non-Meraki VPN connections.
For information on troubleshooting Meraki-to-Meraki VPN, please refer to Site-to-Site VPN Troubleshooting.
Please reference the following knowledge base article that outlines VPN concepts: IPSec and IKE
Cisco Meraki devices have the following requirements for their VPN connections to non-Meraki peers:
The following IKE and IPsec parameters are the default settings used by the MX:
Phase 1 (IKE Policy): 3DES, SHA1, DH group 2, lifetime 8 hours (28800 seconds).
Phase 2 (IPsec Rule): Any of 3DES, DES, or AES; either MD5 or SHA1; PFS disabled; lifetime 8 hours (28800 seconds).
It is recommended to leave these settings as default whenever possible. If required by the remote peer, these parameters can be changed by implementing Custom IPsec Policies.
Note: Non-Meraki VPN peers are organization-wide, so peers will be configured for all such MX devices in an organization. If you want multiple MX's to connect to the same 3rd party VPN peer they will all have the same shared secret.
Non-Meraki VPN connections are established using the primary Internet uplink. In the event the primary uplink fails, the VPN connection will use the secondary Internet uplink. Keep in mind that the third-party peer will need the appropriate configuration for the IP address of the secondary uplink if failover occurs. The primary uplink settings are found under Configure > Traffic shaping > Uplink configuration.
In order to build a VPN between two MX devices in different organizations, a non-Meraki VPN peer connection will be necessary. Please reference our documentation for more info.
Event logs can be displayed from Monitor > Event log. Deselect all event log types with the exception of VPN, and click on the search button. A specific time range can also be defined to narrow the results if you need to know the specific time the issue occurred.
The following log entries show a successful VPN connection between the MX (IP: 126.96.36.199) and a Non-Meraki VPN device (IP:188.8.131.52):
Jan 1 06:50:05 VPN msg: IPsec-SA established: ESP/Tunnel 184.108.40.206->220.127.116.11 spi=122738512(0x750d750) Jan 1 06:50:04 VPN msg: initiate new phase 2 negotiation: 18.104.22.168<=>22.214.171.124 Jan 1 06:50:04 VPN msg: ISAKMP-SA established 126.96.36.199-188.8.131.52 spi:91f7c94b98a41ce8:85abf36d937b096f Jan 1 06:50:03 VPN msg: initiate new phase 1 negotiation: 184.108.40.206<=>220.127.116.11
Review the event log for entries that indicate there has been a failure during phase 1 or 2 negotiation. Here is an example log entry of a phase 1 failure:
May 8 07:23:53 VPN msg: failed to get valid proposal. May 8 07:23:53 VPN msg: no suitable proposal found. May 8 07:23:43 VPN msg: phase1 negotiation failed.
Error Description: Phase 1 can’t be established. The event logs shows the following error is recorded in the event logs in the dashboard “ no-proposal-chosen received in informational exchange”
Error Solution: The error is typically caused by a mismatched configuration between the two VPN appliances. The steps listed below will assist in troubleshooting the issue.
Error Description: The tunnel can’t be established and the event log shows a successful phase 1 negotiation, however the following error message is recorded after phase 2 initiation phase: “ no-proposal-chosen received in informational exchange”.
Error Solution: This can result from mismatched phase 2 security association. Please verify that the third party VPN peer share identical phase 2 parameters, and the following requirements are met:
Error Description: The tunnel can’t be established and the following error is recorded in the event logs in the Dashboard “ msg: failed to pre-process ph2 packet (side: 1, status: 1), msg: failed to get sainfo. ”
Error Solution: This can result from mismatched subnets in the IPsec tunnel definitions, typically a mismatched subnet mask. Check to be sure that the local and remote subnets match up on each side of the VPN tunnel.
Note: This error can come up when attempting to establish a VPN tunnel with Microsoft Azure. For more information, refer to the note on this article regarding Microsoft Azure Troubleshooting.
Error Description: The MX only supports site-to-site VPN using IKEv1. If IKEv2 is configured on the remote end, the message "invalid flag 0x08" may be seen in the event log.
Error Solution: Switch the remote end from using IKE v2 to v1.
Error Description: The MX only supports main mode for phase 1 negotiation. If the non-Meraki peer is configured to use aggressive mode, this error may be seen in the event log, indicating that the tunnel failed to establish.
Error Solution: Change the remote peer's configuration to use main mode for phase 1.
Error Description: One or more peers does not have a valid phase 1 configuration, causing a mismatch between the peers. This can also occur if the remote peer is configured for aggressive mode ISAKMP (which is not supported by the MX), or if the MX receives ISAKMP traffic from a 3rd party peer not configured in Dashboard at all.
Error Solution: Ensure that both peers have matching phase 1 configurations, and that the remote peer is configured for main mode. As a follow-up step, take a packet capture on the MX's primary Internet interface, and filter by IP address and "isakmp" to ensure that both peers are communicating. Also check the IP address and ensure that it is a valid peer that has been added in Dashboard.
Error Description: VPN peer-bound traffic was generated for a non-Meraki VPN peer that we did not already have an established tunnel. In attempting to begin the phase 1 negotiation to establish the tunnel, we did not receive a response back from the remote side.
Error Solution: Use some simple tests (ping, for example) to check for packet loss between the two sites. Take a packet capture to verify that ISAKMP traffic is being sent by the local peer. If the ISAKMP traffic is received and the remote side is not replying, verify that the remote side is configured to establish a tunnel with the local peer.
Error Description: The tunnel is successfully established; however some hosts can’t communicate across the tunnel.
Error Solution: If some hosts are having issues sending traffic across the VPN tunnel and others cannot, it is most likely due to the packets from that client system are not being routed to the MX. The client system either has an incorrect gateway or an incorrect subnet mask.
Error Description: The tunnel is successfully established and traffic can be passed, but after some amount of time the tunnel will go down.
Error Solution: If the phase 2 lifetime does not match between the MX and the remote peer, the tunnel will establish and function normally, until the lower phase 2 lifetime expires. Ensure that the phase 2 lifetime is set identically on both peers (the MX default is 28800 seconds, and the MX does not support data-based lifetimes).
The Event Log can be used to determine if a Non-Meraki VPN connection has been successful, and failure entries can help quickly identify which settings likely do not match between the devices. After ensuring the settings match between the devices, successful negotiation messages indicate that the VPN tunnel has been established. Please reference the following links for vendor specific configuration examples:
Once the VPN configuration has been completed on Microsoft Azure, check the address space(s) designated to traverse the VPN tunnel. This typically includes a supernet (summary address) and its individual subnets. For example, when advertising the networks of 192.168.10.0/24 and 192.168.20.0/24, the supernet would be 192.168.0.0/19.
Within Dashboard, be sure to add the supernet (in our example, 192.168.0.0/19) of your Microsoft Azure networks instead of the individual subnets within the “Non-Meraki Peer - Private Subnets” field. If this is overlooked, then the VPN tunnel will fail to establish due to the mismatched subnets.
Google Cloud supports the use of IPsec VPN, and therefore can function as a VPN peer. Please note that only IKEv1 is supported by the Cisco Meraki security appliance. If IKEv2 is configured on the Google side, the tunnel will not function. In addition, the gateway on Google's side will not respond to ICMP, so ping tests are not valid for testing connectivity.
For additional information, please refer to Google's documentation on setting up Cloud VPN.