IPsec VPN Configuration Example: Cisco ISR Appliance

This example illustrates how to configure two IPsec VPN tunnels from a Cisco ISR appliance to two ZENs: a primary tunnel from the ISR appliance to a ZEN in one data center, and a secondary tunnel from the ISR appliance to a ZEN in another data center.

NOTE: Zscaler IPsec tunnels support a soft limit of 200 Mbps per tunnel. If your organization wants to forward more than 200 Mbps of traffic, Zscaler recommends you configure more IPsec VPN tunnels as needed. For example, if you organization forwards 400 Mbps of traffic, you can configure two primary VPN tunnels and two secondary VPN tunnels. If your organization processes 600 Mbps of traffic, you would configure three primary VPN tunnels and three secondary VPN tunnels.

Organizations typically forward all traffic destined for any port to the Zscaler service. Alternatively, you can limit the traffic that you forward to Zscaler services to HTTP and HTTPS traffic (traffic destined for port 80 and port 443). Regardless, tunneling provides visibility into the internal IP addresses, which can be used for the Zscaler security policies and logging.

Prerequisites

Before you start configuring the Zscaler service and the firewall, ensure that you have the following information for setting up the tunnel:

Loc

  1. Go to ips.<your cloud name>.net

    You can find the name of your cloud in the URL your admins use to log into the Zscaler service. For example, if an organization logs into admin.zscalertwo.net, then that organization's cloud name is zscalertwo.net. Therefore, in this instance, you would go to ips.zscalertwo.net. To learn more, see What is my cloud name?
  2. From the menu on the left, click Cloud Enforcement Node Ranges.
  3. Choose two data centers closest to you. One data center will be the destination for your primary IPsec VPN tunnel, and the other the destination for your secondary IPsec VPN tunnel.
  4. For each data center, locate the GRE Virtual IP and the VPN Host Name.
    • GRE Virtual IP: This is your ZEN IP.
    • VPN Host Name: Resolve this hostname to obtain your VPN IP.

For example, if you're located in London, you can scroll to the Europe section of the table, then choose London as your primary data center and Amsterdam as your secondary data center. In this case:

  • London's VPN IP is the resolution of lon3-vpn.zscalertwo.net, and the ZEN IP is 165.225.80.34
  • Amsterdam's VPN IP is the resolution of amsterdam2-vpn.zscalertwo.net, and the ZEN IP is 185.46.212.34

See image.  

Cloud ENR

Cloud ENR

Configure the Zscaler Service

A.  Enter the VPN credentials.

  1. Go to Administration > Resources > VPN Credentials.
  2. Click Add and do the following:
    • You can choose from three different authentication types: FQDN, XAUTH or IP address. In this deployment scenario, we are using the FQDN option.
    • Enter the pre-shared key in the text box and confirmation box.
    • Optionally, type in comments.
  3. Click Save and activate the change.

B.  Link the VPN credentials to a location.

  1. Go to Administration > Resources > Locations.
  2. Do one of the following:
    • Add a new location or edit a location.
  3. In the Add Location or Edit Location dialog box, click the down arrow beside VPN Credentials and choose the credentials you created.
  4. Click Save and activate the change.

Configure the Cisco ISR

This section provides the CLI configuration commands for the following tested ISR version 15.0. For questions regarding these commands, refer to the Cisco documentation.

CLI configuration for ISR version 15.0

Following is the configuration for the two tunnels. Both tunnels must be configured at your gateway. Only a single tunnel is operational at any time. The second tunnel acts as a backup tunnel. The following text in red represents the values that your organization needs to provide, based on your network setup.

  • inside_interface - Inside interface of the ISR
  • outside_interface - External interface of the ISR
  • abc@test.com - FQDN details set by your organization in the Zscaler interface
  • customer_IP - Customer public IP address on the WAN interface of the ISR
  • vpn_ip_1 & vpn_ip_2 - VPN IP addresses (see how to locate the IP addresses under Prerequisites)
  • monitoring_ip_1 & monitoring_ip_2 - ZEN IP addresses (see how to locate the IP addresses under Prerequisites)
  • password_here - Password set by your organization in the Zscaler interface
  • int_server_ip - Public IP address of any internal web server hosted behind the corporate’s firewall that needs to be accessed from outside.

Note that Cisco routers forward policy-based routing (PBR) traffic in software instead of hardware, which may lead to CPU spikes. You can use 'ip route' instead of PBR to decrease CPU usage.

IPsec Tunnels

! #1: Internet Key Exchange (IKE) Configuration 
! 
! Establish a policy for the supported ISAKMP encryption, authentication Diffie-Hellman, lifetime and 
! key parameters. Note that there is a global list of ISAKMP policies, each identified by sequence 
! number. 
! IMPORTANT: This policy is defined as #1, which may conflict with an existing policy. If so, we 
! recommend changing your existing policy number to something else because the #1 policy must be 
! the Zscaler policy. Otherwise, the tunnel negotiations will fail.

crypto isakmp policy 1  
	encryption 3des   
	authentication pre-share
	hash md5   
	group 2   
	lifetime 86400   
exit 
crypto isakmp keepalive 20 5 periodic  
crypto isakmp nat keepalive 20 
 
!
! The following commands link the crypto map with ZEN’s public IP, password and FQDN.
! 

crypto isakmp peer address vpn_ip_1
	set aggressive-mode password password_here
	set aggressive-mode client-endpoint user-fqdn abc@test.com
crypto isakmp peer address vpn_ip_2
	set aggressive-mode password password_here
	set aggressive-mode client-endpoint user-fqdn abc@test.com
!
!-------------------------------------------------------------------------------------------------------------------------------------------------
! #2: IPsec Configuration 
!  
! The IPsec transform set defines the encryption, authentication, and IPsec mode parameters.  
! NOTE: Zscaler supports both AES and null encryption. Zscaler recommends using null encryption, as shown in
! the example below, because it reduces the load on the local router/firewall for traffic destined for the 
! Internet. But if you would like to use AES, you may purchase a separate subscription and use the 
! command "esp-aes".

crypto ipsec transform-set transform-zen esp-null esp-md5-hmac 
 
! The IPsec profile references the transform set and further defines the various other parameters 
! used such as security association lifetime. You can also enable the IPsec fragmentation after
! encryption.

crypto ipsec fragmentation after-encryption
crypto ipsec profile ZEN
	set security-association lifetime seconds 28800
	set security-association idle-time 28800
	set transform-set transform-zen
!--------------------------------------------------------------------------------------------------------------------------------------------------
! #3: Tunnel Interface Configuration 
! A tunnel interface is configured to be the logical interface associated with the tunnel. All traffic 
! routed to the tunnel interface will be encrypted and transmitted to the ZEN. Similarly, traffic from 
! the ZEN will be logically received on this interface.
! Association with the IPSec security association is done through the "tunnel protection" command.

interface Tunnel1
	ip unnumbered outside_interface
	tunnel source outside_interface
	ip mtu 1400
	ip tcp adjust-mss 1300
	tunnel mode ipsec ipv4
   tunnel destination vpn_ip_1
	tunnel protection ipsec profile ZEN
interface Tunnel2
	ip unnumbered outside_interface
	tunnel source outside_interface
	ip mtu 1400
	ip tcp adjust-mss 1300
	tunnel mode ipsec ipv4
	tunnel destination vpn_ip_2
	tunnel protection ipsec profile ZEN
exit
!--------------------------------------------------------------------------------------------------------------------------------------------------
! #4: Access List & Route Map Configuration
! Access lists are configured to permit the creation of tunnels and to send relevant traffic over them.
! Organizations typically forward all traffic to Zscaler. Alternatively, they can also restrict it to be 
! HTTP/HTTPS (port 80 and 443).  You should also create a deny list with all the appropriate server
! public IP addresses that you don’t want to flow through the tunnel. One such example would be an 
! internally hosted Web server. 

access-list 101 deny tcp int_server_ip any
access-list 101 permit icmp any any
access-list 101 permit tcp any any

! 
! The following route map is configured which links the ACL with tunnel interfaces. This policy is 
! defined as #1, which may conflict with an existing policy using the same number. If so, we 
! recommend changing the policy number to avoid conflicts.

route-map Z-PBR permit 1
	match ip address 101
	set ip next-hop verify-availability vpn_ip_1 1 track 1
	set ip next-hop verify-availability vpn_ip_2 2 track 2
exit
interface inside_interface
	ip policy route-map Z-PBR
!--------------------------------------------------------------------------------------------------------------------------------------------------
! #5: VPN Monitoring using IP SLA’s
! SLA Monitor is used to provide a failover between the two tunnels. If the primary tunnel fails, the
! redundant tunnel will automatically be used. This sla is defined as #1 & #2, which may conflict 
! with an existing sla using the same number. If so, we recommend changing the sequence number to 
! avoid conflicts. 
! Ensure that zen_ip_1 and zen_ip_2 are reachable and routable through the tunnel. 
! Zscaler recommends that you specify the following URL gateway.zscaler_cloud.net/vpntest, as shown below.
! For information on how to determine the Zscaler cloud name, see What is my cloud name? 

config IP SLA
ip route monitoring_ip_1 255.255.255.255 Tunnel1 permanent
ip route monitoring_ip_2 255.255.255.255 Tunnel2 permanent
track 1 ip sla 1
track 2 ip sla 2
ip sla 1
	 http raw http://monitoring_ip_1:443
		  timeout 5000	
	      threshold 300
	      http-raw-request
		       GET http://gateway.zscaler-cloud.net/vpntest HTTP/1.0\r\n
		       User-Agent: Cisco IP SLA\r\n
		       end\r\n
  		       \r\n
 		       exit
	  exit
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react rtt threshold-value 300 1 threshold-type consecutive 3
ip sla 2
	 http raw http://monitoring_ip_2:443
		 timeout 5000
        threshold 300
	     http-raw-request
		      GET http://gateway.zscaler-cloud.net/vpntest HTTP/1.0\r\n
		      User-Agent: Cisco IP SLA\r\n
		      end\r\n
  		      \r\n
 		      exit
	     exit
ip sla schedule 2 life forever start-time now
ip sla reaction-configuration 2 react rtt threshold-value 300 1 threshold-type consecutive 3

 

Troubleshooting

The following troubleshooting tips can be used while setting up the tunnels. The text in red represents the value that you should look out for while troubleshooting issues in your setup.

Use the following command for troubleshooting Phase 1 of the tunnel. The response shows an organization’s gateway with IKE configured correctly. The status value should be ACTIVE, which indicates that the tunnel is active.

ciscoisr# show crypto isakmp sa    
IPv4 Crypto ISAKMP SA
dst 	            src 	    state          conn-id 	   status
zen_ip_1	    customer_IP     QM_IDLE           2012 	   ACTIVE
zen_ip_2	    customer_IP     AG_INIT_EXCH      2011 	   ACTIVE

IPv6 Crypto ISAKMP SA

 

Use the following command for troubleshooting Phase 2 of the tunnel. The response shows an organization’s gateway with IKE configured correctly. Customers should ensure that some packets are encapsulated and de-capsulated. This indicates that traffic is indeed flowing through the tunnel.

ciscoisr# show crypto ipsec sa 
interface: Tunnel1	 
	Crypto map tag: Tunnel1-head-0, local addr: corp_public_addr 
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)	   
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)	   
current_peer: zen_ip_1 port 500
	 PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: corp_public_addr, remote crypto endpt.: zen_ip_1

path mtu 1400, ip mtu 1400, ip mtu idb FastEthernet4
current outbound spi: 0xBDC1E53(198975059)
PFS (Y/N): N, DH group: none

inbound esp sas:
	spi: 0xDF685FC2(3748159426)
		transform: esp-aes128 esp-md5-hmac ,
		in use settings ={Tunnel, }
		conn id: 1, flow_id: Onboard VPN:1, sibling_flags 80000046, crypto map: 
Tunnel1-head-0
		sa timing: remaining key lifetime (k/sec): (4552507/14113)
		IV size: 8 bytes
		replay detection support: Y
		Status: ACTIVE

	 inbound ah sas:

	 inbound pcp sas:
  
outbound esp sas:
	spi: 0xBDC1E53(198975059)
		transform: esp-null esp-md5-hmac ,
		in use settings ={Tunnel, }
		conn id: 2, flow_id: Onboard VPN:2, sibling_flags 80000046, crypto map: 
Tunnel1-head-0
		sa timing: remaining key lifetime (k/sec): (4552507/14113)
		IV size: 8 bytes
		replay detection support: Y
		Status: ACTIVE

	 outbound ah sas:

	 outbound pcp sas:

interface: Tunnel2	 
	Crypto map tag: Tunnel2-head-0, local addr: corp_public_addr 
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)	   
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)	   
current_peer: zen_ip_2 port 500
	 PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: corp_public_addr, remote crypto endpt.: zen_ip_2

path mtu 1400, ip mtu 1400, ip mtu idb FastEthernet4
current outbound spi: 0xBDC1E53(198975059)
PFS (Y/N): N, DH group: none

	 inbound esp sas:
	 inbound ah sas:
	 inbound pcp sas:

	 outbound esp sas
	 outbound ah sas:
	 outbound pcp sas:

The following command can be used to track the IP SLA status:

ciscoasa# show track
Track 1
 IP SLA 1 reachability
 Reachability is Down
	3 changes, last change 00:16:23
 Latest operation return code: Timeout
Track 2
 IP SLA 2 reachability
 Reachability is Up
	2 changes, last change 01:01:27
 Latest operation return code: OK
 Latest RTT (millisecs) 1

The following command can be used to view the SLA statistics:

ciscoisr# show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 2
Number of successes: Unknown
Number of failures: Unknown
Operation time to live: 0


IPSLA operation id: 1
		Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *02:29:07.511 UTC Mon Nov 10 2014
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 2
Operation time to live: Forever

IPSLA operation id: 2
		Latest RTT: 1 milliseconds
Latest operation start time: *02:29:10.719 UTC Mon Nov 10 2014
Latest operation return code: OK
Number of successes: 2
Number of failures: 0
Operation time to live: Forever

Simulate a fail condition for tunnel 1 and verify that a failover to tunnel 2 occurs.

ciscoisr# show crypto session
Crypto session current status

Interface: Tunnel2
Session status: UP-ACTIVE
Peer: zen_ip_2 port 500
 IKEv1 SA: local corp_public_addr/500 remote zen_ip_2/500 Active
 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
		Active SAs: 2, origin: crypto map

Interface: Tunnel1
Session status: DOWN-NEGOTIATING
Peer: zen_ip_1 port 500
 IKEv1 SA: local corp_public_addr/500 remote zen_ip_1/500 Inactive
 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
		Active SAs: 0, origin: crypto map