Troubleshooting Non-Meraki Site-to-site VPN

Last updated
Save as PDF

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.

Cisco Meraki VPN Settings and Requirements

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:

Preshared keys (no certificates).
LAN static routes (no routing protocol for the VPN interface).
Time-based lifetimes (data-based lifetimes are not supported)
Access through UDP ports 500 and 4500.
IKEv1 in Main Mode or IKEv2

Note: IKEv2 is only supported on Security Appliances that are running firmware version 15.12 or higher - if you do not see an option to configure it, please ensure your appliance is configured to run the appropriate version, and is not incompatible with the required release.

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 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.

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 3rd 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 Security & SD-WAN > Configure > SD-WAN & traffic shaping > Uplink selection > Global preferences > Primary uplink.

You must generate Interesting Traffic in order to bring the tunnel up. You can do it by initiating a ping from a host inside a VPN enabled subnet into an IP address in the remote subnet.

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 information.

Troubleshooting with the Event Log

NOTE: The information from this point forward in this article only applies to Non-Meraki VPN Connections running firmware prior to MX15.12

Event logs can be displayed from Network-wide > Monitor > Event log. Select the All Non-Meraki / Client VPN event log type as the sole Event type include option 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.

Screenshot the Event log. The "Event type include:" field is set to "All Non-Meraki / Client VPN".

The following log entries show a successful VPN connection between the MX (IP: 1.1.1.1) and a Non-Meraki VPN device (IP:2.2.2.2):

Jan 1 06:50:05 VPN msg: IPsec-SA established: ESP/Tunnel 1.1.1.1[4500]->2.2.2.2[4500] spi=122738512(0x750d750)
Jan 1 06:50:04 VPN msg: initiate new phase 2 negotiation: 1.1.1.1[4500]<=>2.2.2.2[4500]
Jan 1 06:50:04 VPN msg: ISAKMP-SA established 1.1.1.1[4500]-2.2.2.2[4500] spi:91f7c94b98a41ce8:85abf36d937b096f
Jan 1 06:50:03 VPN msg: initiate new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]

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.

Event Log: "no-proposal-chosen received" (Phase 1)

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.

Verify that phase 1 parameters match
Check that each side can reach the peer address described in the tunnel
Verify ISAKMP is enabled on the outbound interface

Event Log: "no-proposal-chosen received" (Phase 2)

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 a mismatched phase 2 security association. Please verify that the third party VPN peer shares identical phase 2 parameters, and the following requirements are met:

Lifetime: Time-based lifetime (do not use data-based lifetimes)
IKE Version: v1/v2
Mode: Use tunnel mode instead of transport mode for VPN

Event Log: "failed to pre-process ph2 packet/failed to get sainfo"

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.

This error can come up when attempting to establish a VPN tunnel with Microsoft Azure. For more information, refer to the section in this article regarding Microsoft Azure Troubleshooting.

Event Log: "invalid flag 0x08"

Error Description: The MX supports site-to-site VPN using IKEv1 and IKEv2 (IKEv2 supported on MX appliances running firmware 15.12 or higher). If the IKE versions do not match what is configured on each end, the message "invalid flag 0x08" may be seen in the event log.

Error Solution: Confirm the IKE version being used on the remote peer is compatible with the MX appliance. If the MX the remote peer is attempting to establish the tunnel to is running on a firmware version lower than 15.12, then switch the remote end from using IKE v2 to v1.

Event Log: "exchange Aggressive not allowed in any applicable rmconf"

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.

Event Log: "exchange Identity Protection not allowed in any applicable rmconf."

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.

Event Log: "phase1 negotiation failed due to time up"

Error Description: VPN peer-bound traffic was generated towards a non-Meraki VPN peer for which 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.

Some hosts can communicate across the tunnel others can’t

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.

The tunnel goes down regularly after some time

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.

Vendor-specific examples and limitations

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:

Microsoft Azure

One of the most common site-to-site VPN issues between a Cisco Meraki appliance and Microsoft Azure is caused by mismatched local/remote subnets, as described above.

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 peers > Private subnets field. If this is overlooked, then the VPN tunnel will fail to establish due to the mismatched subnets.

Please note that due to compatibility limitations between the Meraki MX and Microsoft Azure Gateways, site-to-site VPN connections between the MX and Azure VNet Gateways may experience occasional instability when using firmware prior to MX 15 and IKEv1 for the connection. We recommend that customers use MX15+ firmware with IKEv2 or the vMX network virtual appliance found in the Azure Marketplace for optimal site-to-site VPN performance, stability, and visibility.

AWS

AWS tunnels established to Amazon’s hardware endpoints limits the number of active Security Association pairs to two. In effect, this means that only two local subnets on the MX side can only communicate with two remote subnets on the AWS side, and that initiating traffic on a third subnet pair will break one of the previously established tunnels. Reference documentation here:

"You are limited to one unique security association (SA) pair per tunnel (one inbound and one outbound), and therefore two unique SA pairs in total for two tunnels (four SAs)."

To avoid this limitation, Meraki recommends upgrading to MX 15.x or higher firmware and using IKEv2 whenever possible. MXs using IKEv2 bundle all local and remote subnets into a single Security Association, which means any number of subnets on both parties can participate in a VPN tunnel without restriction.

Google Cloud VPN Troubleshooting

Google Cloud supports the use of IPsec VPN, and therefore can function as a VPN peer. Please note that MX appliances running firmware below version 15.12 will only support IKEv1. If IKEv2 is configured on the Google side, the tunnel will not function. You will either need to configure the Google side to use IKEv1, or upgrade the MX to firmware version 15.12 or higher if IKEv2 is a requirement. 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.