Cisco Secure Connect - Non-Meraki IPSec Tunnel
Overview
An IPsec (Internet Protocol Security) IKEv2 (Internet Key Exchange, version 2) tunnel is used to securely forward traffic from Cisco Umbrella to the destination networks of the private applications. For more details on supported IPSec parameters, reference Supported IPSec parameters
Creating a New Tunnel
1. Navigate to Secure Connect > Network Tunnels. This will open Deployments > Core Identities > Network Tunnels configuration page.
Figure 1: Network Tunnels
2. Click Add in the upper right hand corner of the screen
3. Enter a Tunnel Name, select the correct datacenter Device Type and click Save
Figure 2: Add a secure access tunnel
Maximum Transmission Unit (MTU) Size
Umbrella does not support the reassembly of fragmented IPSec traffic or IP packets for internet traffic. Thus, when a network device sends fragmented IPSec or IP packets to Umbrella, Umbrella drops the fragmented packets. IPSec tunnels for Secure Internet Access must have an MTU no larger than 1280 bytes. Fragmented packets in underlay or overlay are dropped.
4. Set a Tunnel ID and Passphrase. These values must match the respective values on the datacenter device. For more details see: Network Tunnel Configuration
-
For Cisco devices, reference the instructions here
-
For non-Cisco devices, reference the instructions here
Figure 3: Add Tunnel ID and Passphrase
5. Select Service Type as Secure Internet Access or Private Access.
For Secure Internet Access, you will need to add all public and private address ranges used internally by your organization.
Figure 4: Configure Secure Internet Access service
For Private Access, you will need to add IP ranges and CIDR addresses of your private applications for route advertisement.
Figure 5: Configure Private Access service
Secure Connect IPSec Headend Data Centers
Please note that the following DC's are enabled for Secure Connect so please use the below IP while connecting to the tunnel headend.
Region | City | IP Address | FQDN |
---|---|---|---|
Americas |
Los Angeles, CA, US |
146.112.67.8 |
us1-a.vpn.sig.umbrella.com |
Americas |
Palo Alto, CA, US |
146.112.66.8 |
us1-b.vpn.sig.umbrella.com |
Americas |
New York, NY, US |
146.112.83.8 |
us2-a.vpn.sig.umbrella.com |
Americas |
Ashburn, VA, US |
146.112.82.8 |
us2-b.vpn.sig.umbrella.com |
Americas |
Miami, FL, US |
146.112.84.8 |
us3-a.vpn.sig.umbrella.com |
Americas |
Atlanta, GA, US |
146.112.85.8 |
us3-b.vpn.sig.umbrella.com |
Americas |
Dallas-Fort Worth, TX, US |
146.112.72.8 |
us4-a.vpn.sig.umbrella.com |
Americas |
Denver, CO, US |
146.112.73.8 |
us4-b.vpn.sig.umbrella.com |
Americas |
Minneapolis, MN, US |
146.112.81.8 |
us5-a.vpn.sig.umbrella.com |
Americas |
Chicago, IL, US |
146.112.80.8 |
us5-b.vpn.sig.umbrella.com |
EMEA |
London, United Kingdom |
146.112.97.8 |
eu1-a.vpn.sig.umbrella.com |
EMEA |
Frankfurt, Germany |
146.112.96.8 |
eu1-b.vpn.sig.umbrella.com |
EMEA |
Paris, France |
146.112.102.8 |
eu2-a.vpn.sig.umbrella.com |
EMEA |
Prague, Czech Republic |
146.112.103.8 |
eu2-b.vpn.sig.umbrella.com |
EMEA |
Copenhagen, Denmark |
146.112.100.8 |
eu3-b.vpn.sig.umbrella.com |
EMEA |
Stockholm, Sweden |
146.112.101.8 |
eu3-a.vpn.sig.umbrella.com |
EMEA |
Milan, Italy |
146.112.107.8 |
eu4-a.vpn.sig.umbrella.com |
EMEA |
Madrid, Spain |
146.112.106.8 |
eu4-b.vpn.sig.umbrella.com |
Africa |
Johannesburg, South Africa |
146.112.108.8 |
af1-a.vpn.sig.umbrella.com |
Africa |
Cape Town, South Africa |
146.112.109.8 |
af1-b.vpn.sig.umbrella.com |
Asia |
Singapore, Singapore |
146.112.113.8 |
as1-a.vpn.sig.umbrella.com |
Asia |
Tokyo, Japan |
146.112.112.8 |
as1-b.vpn.sig.umbrella.com |
Asia |
Sydney, Australia |
146.112.118.8 |
au1-a.vpn.sig.umbrella.com |
Asia |
Melbourne, Australia |
148.112.119.8 |
au1-b.vpn.sig.umbrella.com |
Canada |
Toronto, Canada |
146.112.65.8 |
ca1-a.vpn.sig.umbrella.com |
Canada |
Vancouver, Canada |
146.112.64.8 |
ca1-b.vpn.sig.umbrella.com |
South America |
São Paulo, Brazil |
146.112.92.8 |
br1-a.vpn.sig.umbrella.com |
South America |
Rio de Janeiro, Brazil |
146.112.93.8 |
br1-b.vpn.sig.umbrella.com |
Multiple Tunnels
Each manual IPSec tunnel is limited to approximately 250 Mbps. To achieve higher throughput, we can establish multiple tunnels. Creating multiple tunnels from the same device. For more details, see examples in Multiple Tunnels Load Sharing and Can-I-create-multiple-IPSEC-Tunnels.
If you set up multiple tunnels, there are limitations to follow:
- A unique set of Network Tunnel credentials must be used for each IPSec tunnel. Two IPSec tunnels cannot connect to the same data center with the same credentials (IP addresses) at the same time. Using 2 different public IP addresses on the customer device, or two different loopback addresses that are NATed using different port numbers will activate the both tunnels at the same time. Example how to accomplish this can be found here.
- For Secure Internet Access, all traffic should be initiated from behind the IPSec tunnel. We recommend that you divide the traffic between the tunnels either through load balancing with ECMP (Equal-cost multi-path routing) or assigning traffic through policy-based routing. Overlapping IPs in Edge devices is supported and ECMP is supported only if tunnels are terminating at the same Data Center headend. This configuration is done on customer device if supported.
- For Secure Private Access, remote access users or branch users will be initiating traffic toward the servers behind the IPSec tunnel. Overlapping IPs is not recommended as it can cause unexpected behaviour with routing.
-
If a tunnel is showing as “Not Established” (Deployments > Network Tunnels page) check the device has been configured using our supported IPsec paramters.
-
If a tunnel is showing as “Inactive” ensure traffic is being generated which should be routed down the VPN.
Figure 4: Return to Secure Connect link
-
In the upper right hand corner of the screen, click Return TO SECURE CONNECT.
Once the tunnel is established traffic will not flow until traffic, such as a ping, is sent from the network where the private application resides. Once this is complete, traffic will flow bidirectionally.
Modifying Tunnel
Presently, the IPSec tunnel for Secure Connect is configured in the Umbrella dashboard. To modify the IPsec tunnel settings, please follow the following steps.
Accessing Tunnel Edit Options
- From the Meraki Secure Connect dashboard, navigate to the Secure Connect menu > Identities & Connections > click on the Network Tunnel link. The page will be redirected to the Umbrella dashboard where you can configure the Deployments > Core Identities > Network Tunnels.
- From the Network Tunnels page > click on the horizontal ellipsis button (. . .) next to the private tunnel that you would like to make the change > and then click Details.
- Within the Network Tunnels details page > click on the horizontal ellipsis button (. . .) > and then click Edit to show the Tunnel Edit options.
The following are the available tunnel settings that can be modified:
- Tunnel Name
- Tunnel ID
- Passphrase
- Client Reachable Prefixes
Update Tunnel ID
From the Network Tunnel edit options > click Edit under the Tunnel ID to access the Update Tunnel ID popup window > enter New Tunnel ID name > click the acknowledgment checkbox > and then click Save.
Update Tunnel Passphrase
From the Network Tunnel edit options > click Edit under the Passphrase to access the Update Tunnel Passphrase popup window > enter New Passphrase and Confirm Passphrase > click the acknowledgment checkbox > and then click Save.
Edit Client Reachable Prefixes
From the Network Tunnel edit options > click Edit under the Client Reachable Prefixes to access the Edit Client Reachable Prefixes popup window > enter the IP ranges and CIDR addresses that remote users need to access via the IPSec tunnel > click on the checkbox to Acknowledge Disconnect & Reconnect Requirement > and then click Save.
Please note route changes do not apply until you manually disconnect and then reconnect the IPsec tunnel.