Networking Fundamentals: IPSec and IKE
Cisco Meraki uses IPSec for Site-to-site and Client VPN. IPSec is a framework for securing the IP layer. In this suite, modes and protocols are combined to tailor fit the security methods to the intended use. Cisco Meraki VPNs use the following mode+protocol for Site-to-Site VPN communication:
Mode: Tunnel
In tunnel mode, the entire IP header and payload is encapsulated. This means that a new packet header will be added and the packet itself can be encrypted, as opposed to just the packet’s data. This allows traffic to be passed in it's entirety and create a secure channel for communication between two endpoints.
Protocol: Encapsulated Security Payload (ESP)
ESP is the wire-level protocol designed to secure communication by encrypting the encapsulated data and can allow for authentication.
ESP being used in tunnel mode allows for encryption of the full packet. To an entity viewing this traffic externally, the only clear-text data in the packets are the new IP header and the ESP header:
IPSec can also be used in both transport mode and the AH protocol. Each mode can be used with either protocol, but the above combination is used because it best suits a secured VPN connection. Each side of an IPSec communication needs to share secret values to secure traffic. These keys are used to match encryption and hashing methods. There are two distinct methods that Cisco Meraki devices use to establish these keys.
The foremost method that Cisco Meraki devices use to establish shared secrets is through the Cisco Meraki cloud infrastructure. All Meraki devices have a secured tunnel back to the Cisco Meraki cloud. This allows Cisco Meraki devices to establish all information needed to create an IPSec tunnel through this mutually trusted source. A method known as UDP holepunching is then used to create these VPN tunnels. For more info on how the Meraki MX uses UDP hole punching, please refer to our documentation on Automatic NAT Traversal.
Cisco Meraki devices also utilize the well known IKE method for negotiating the essential information for IPSec connections. This method is used for client VPN and Non-Meraki site-to-site VPNs.
IKEv1
Internet Key Exchange (IKE) is the protocol Cisco Meraki uses to establish IPSec connections for Non-Meraki site-to-site and client VPNs. When a VPN endpoint sees traffic that should traverse the VPN, the IKE process is then started. IKE is broken down into 2 phases:
Phase 1
The purpose of this phase is to create a secure channel using a diffie-hellman key exchange. This secure channel is then used for further IKE transmissions. Phase 1 is based off of the ISAKMP framework. In the above figure, we can see the Cisco Meraki Event Log entries that will typically accompany the IKE process. Please note that in a successful exchange, the logs should display “ISAKMP-SA established” and some information specific to that association.
Phase 1 has two possible modes; main mode and aggressive mode. Main mode consists of three exchanges to process and validate the diffie-hellman exchange while aggressive mode does so within a single exchange.
Issues with this phase are usually related to public IP addressing, pre-shared keys, or encryption/hash configuration.
Phase 2
Using the channel created in phase 1, this phase establishes IPSec security associations and negotiates information needed for the IPSec tunnel. This phase can be seen in the above figure as “IPsec-SA established.” Note that two phase 2 events are shown, this is because a separate SA is used for each subnet configured to traverse the VPN.
This phase has only one mode on the Cisco Meraki platform, called quick mode.
Issues with this phase are typically seen when subnets are not matched on each side of the tunnel or permitted encryption/hash settings are mismatched.
Additional Resources
For information on troubleshooting Cisco Meraki VPN, please refer to the following articles:
For more information on configuring Site-to-Site VPN tunnels: