Home > Security Appliances > Site-to-site VPN > Troubleshooting Non-Meraki Site-to-site VPN Peers

Troubleshooting Non-Meraki Site-to-site VPN Peers

如欲查看中文版本,请点击 这里

 

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).
  • IKEv1 (IKEv2 not supported) in Main Mode (aggressive mode not supported).
  • Access through UDP ports 500 and 4500.

 

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.

Troubleshooting with the Event Log

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

  1. Verify that phase 1 parameters match
  2. Verify pre-shared-keys are the same.
  3. Check that each side can reach the peer address described in the tunnel
  4. 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 mismatched phase 2 security association. Please verify that the third party VPN peer share identical phase 2 parameters, and the following requirements are met:

  • Lifetime: Time-based lifetime (do not use data based lifetimes)
  • IKE Version: v1 (IKEv2 not supported)
  • ASA needs to be in 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.

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.

 

Event Log: "invalid flag 0x08"

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.

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

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

Conclusions and vendor-specific examples

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 Troubleshooting

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

Google Cloud VPN Troubleshooting

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.

You must to post a comment.
Last modified
17:08, 12 Sep 2017

Tags

Classifications

This page has no classifications.

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community