icon-zia.svg
Secure Internet and SaaS Access (ZIA)

IPSec VPN Configuration Guide for Cisco 881 ISR

This article uses only sample IP addresses in the configuration steps and screenshots. For tunnel interface configuration, you must use only RFC 1918 IP addresses and not APIPA addresses.

This article illustrates how to configure two IPSec VPN tunnels from a Cisco 881 Integrated Services Router (ISR) to two ZIA Public Service Edges: a primary tunnel from the router to a ZIA Public Service Edge in one data center and a secondary tunnel from the router to a ZIA Public Service Edge in another data center.

A network diagram showing the primary and secondary IPSec tunnels from a Cisco ISR appliance to two Zscaler ZIA Public Service Edges.

Zscaler IPSec tunnels support a limit of 400 Mbps for each public source IP address. If your organization wants to forward more than 400 Mbps of traffic, Zscaler recommends using one of the following configurations:

  • Configure multiple IPSec tunnels with different public source IP addresses.
  • Configure multiple IPSec VPN tunnels with the same public source IP address using Network Address Translation Traversal (NAT-T) and source port randomization with IKEv2.

For example, if your organization forwards 800 Mbps of traffic, you can configure two primary VPN tunnels and two backup 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 to HTTP and HTTPS traffic (i.e., 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

Ensure you have the following information for setting up the IPSec VPN tunnels:

If you are unable to ping both ZIA Public Service Edge IP addresses, contact Zscaler Support.

Configuring the IPSec VPN Tunnel in the ZIA Admin Portal

In this configuration example, the peers are using an FQDN and a pre-shared key (PSK) for authentication.

To configure the IPSec VPN tunnels in the ZIA Admin Portal:

  1. Add the VPN Credential

You need the FQDN and PSK when linking the VPN credentials to a location and creating the IKE gateways.

  1. Link the VPN Credentials to a Location

Configuring the IPSec VPN Tunnel on Cisco 881 ISR

This article only covers the configuration details of IPSec VPN tunnels between the Cisco 881 ISR and the ZIA Public Service Edges. For any other specific information about the Cisco 881 ISR, refer to the Cisco documentation.

This section describes how to configure two IPSec VPN tunnels on Cisco 881 ISR running Cisco IOS 15.4(3)M3. 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. This configuration uses CLI commands. To learn more about these commands, refer to the Cisco documentation. You must have a Cisco 881 ISR running Cisco IOS version 15.1.1T or later to configure IKEv2.

You must provide the following information to configure the tunnels:

  • <FQDN> - The FQDN of the VPN credentials you created in the ZIA Admin Portal.
  • <Pre-Shared Key> - The pre-shared key of the VPN credentials you created in the ZIA Admin Portal.
  • <LAN Interface> - The LAN interface of the ISR.
  • <WAN Interface> - The WAN interface of the ISR.
  • <MTU> - The optimal MTU for the tunnels.
  • <Primary VPN IP Address> and <Backup VPN IP Address> - The IP addresses of the ZIA Public Service Edges.
  • <Primary Global ZIA Public Service Edge IP Address> and <Backup Global ZIA Public Service Edge IP Address> - The global IP addresses of the ZIA Public Service Edges.
  • <Exempted Server IP> - Traffic to this IP address or IP subnet is not sent through the VPN tunnels to Zscaler. The IP address or IP subnet can be an internal server farm reachable through a router or an external public IP address that must be excluded from being routed through the tunnel.
  • <Zscaler Cloud> - Your Zscaler cloud name.

To configure the IPSec VPN tunnel on Cisco 881 ISR:

Zscaler does not support Extended Sequence Number (ESN) based proposals during IPSec tunnel negotiation.

  • Configure the IKEv2 proposal to negotiate the IKEv2 SA in the IKE_SA_INIT exchange. The IKEv2 proposal defines the encryption algorithm, authentication method, data integrity algorithm, and Diffie-Hellman group parameters used for the IKE negotiation.

    Enter the following commands:

    crypto ikev2 proposal <Proposal Name>
         encryption aes-cbc-256
         integrity sha1
         group 14              

    You need the <Proposal Name> for 2. Configure the IKEv2 Policy.

    Close
  • Configure the IKEv2 policy to associate with the IKEv2 proposal. The IKEv2 policy defines the proposal used during the IKE negotiation. You need the <Proposal Name> created in 1. Configure the IKEv2 Proposal.

    Enter the following commands:

    crypto ikev2 policy <Policy Name>
         match fvrf any
         proposal <Proposal Name>             
    Close
  • Configure the IKEv2 key ring if the peer authentication method is a PSK.

    Enter the following commands:

    crypto ikev2 keyring <Key Ring Name>
         peer <Peer 1 Name>
          address <Primary VPN IP Address>
          pre-shared-key <Pre-Shared Key>
         peer <Peer 2 Name>
          address <Backup VPN IP Address>
          pre-shared-key <Pre-Shared Key>                 

    You need the <Key Ring Name> for 4. Configure the IKEv2 Profiles.

    Close
  • Configure two IKEv2 profiles to define the nonnegotiable parameters for the IKE SA. You need the <Key Ring Name> created in 3. Configure the IKEv2 Key Ring.

    Enter the following commands:

    crypto ikev2 profile <IKEv2 Profile 1 Name>
         match identity remote address <Primary VPN IP Address>
         identity local email <FQDN>
         authentication remote pre-share
         authentication local pre-share
         keyring local <Key Ring Name>
         lifetime 86400
         no config-exchange request
        crypto ikev2 profile <IKEv2 Profile 2 Name>
         match identity remote address <Backup VPN IP Address>
         identity local email <FQDN>
         authentication remote pre-share
         authentication local pre-share
         keyring local <Key Ring Name>
         lifetime 86400
         no config-exchange request                      

    You need the <IKEv2 Profile 1 Name> and <IKEv2 Profile 2 Name> for 9. Configure the IPSec Profiles and 10. Create the Tunnel Interfaces.

    Close
  • Enter the following command:

    crypto ikev2 dpd 10 5 periodic
    Close
  • Enter the following command:

    crypto ikev2 nat keepalive 20
    Close
  • The IPSec transform set defines the encryption, authentication, and IPSec mode parameters for the IKE_AUTH exchange.

    Enter the following commands:

    crypto ipsec transform-set <Transform Set Name> esp-aes-gcm-256 esp-sha-hmac
         mode tunnel

    For Phase 2, Zscaler recommends using AES-GCM-based ciphers if you have purchased a separate encryption SKU. If you do not have a separate subscription, Zscaler recommends using NULL encryption.

    You need the <Transform Set Name> for 9. Configure the IPSec Profiles.

    Close
  • Enable IPSec fragmentation after the encryption.

    Enter the following command:

    crypto ipsec fragmentation after-encryption 
    Close
  • Configure two IPSec profiles to associate with your IKEv2 profiles. You need the <Transform Set Name> created in 7. Define the IPSec Transform Set and the <IKEv2 Profile 1 Name> and <IKEv2 Profile 2 Name> created in 4. Configure the IKEv2 Profiles.

    Enter the following commands:

    crypto ipsec profile <IPSec Profile 1 Name>
         set security-association lifetime seconds 28800
         set security-policy limit 1
         set transform-set <Transform Set Name>
         set ikev2-profile <IKEv2 Profile 1 Name>
        crypto ipsec profile <IPSec Profile 2 Name>
         set security-association lifetime seconds 28800
         set security-policy limit 1
         set transform-set <Transform Set Name>
         set ikev2-profile <IKEv2 Profile 2 Name>
        

    You need the <IPSec Profile 1 Name> and <IPSec Profile 2 Name> for 10. Create the Tunnel Interfaces.

    Close
  • Create two tunnel interfaces that are associated with your IPSec and IKEv2 profiles. All traffic routed to the tunnel interface is encrypted and transmitted to the ZIA Public Service Edge. Similarly, traffic from the ZIA Public Service Edge is logically received on the interface. You can use the tunnel protection command to associate the interfaces with the Child SA.

    You need the <IPSec Profile 1 Name> and <IPSec Profile 2 Name> created in 9. Configure the IPSec Profiles and the <IKEv2 Profile 1 Name> and <IKEv2 Profile 2 Name> created in 4. Configure the IKEv2 Profiles.

    Enter the following commands:

    interface <Primary Tunnel Interface>
         ip unnumbered <WAN Interface>
         ip mtu <MTU>
         ip tcp adjust-mss 1360
         tunnel source <WAN Interface>
         tunnel mode ipsec ipv4
         tunnel destination <Primary VPN IP Address>
         tunnel protection ipsec profile <IPSec Profile 1 Name> ikev2-profile <IKEv2 Profile 1 Name>
        interface <Backup Tunnel Interface>
         ip unnumbered <WAN Interface>
         ip mtu <MTU>
         ip tcp adjust-mss 1360
         tunnel source <WAN Interface>
         tunnel mode ipsec ipv4
         tunnel destination <Backup VPN IP Address>
         tunnel protection ipsec profile <IPSec Profile 2 Name> ikev2-profile <IKEv2 Profile 2 Name>               

    You need the <Primary Tunnel Interface> and <Backup Tunnel Interface> for 12. Define the Route Map and 14. Configure IP SLA for VPN Monitoring.

    Close
  • Create an ACL to send relevant traffic through the tunnel. Most organizations forward all traffic to Zscaler. You can use any of the following commands to configure your ACL:

    • If you want to send all traffic through the tunnel, enter the following:
    access-list <ACL Number> permit ip any any
    • If you only want to send web traffic (i.e., HTTP and HTTPS) through the tunnel, enter the following:
    access-list <ACL Number> permit tcp any any eq 80
        access-list <ACL Number> permit tcp any any eq 443
    • If you want traffic to a web server to be exempted from going through the tunnel, enter the following:
    access-list <ACL Number> deny ip any <Exempted Server IP>
        access-list <ACL Number> permit tcp any any eq 80 
        access-list <ACL Number> permit tcp any any eq 443              

    You need the <ACL Number> for 12. Define the Route Map.

    Close
  • Define a route map that links the ACL with the tunnel interfaces. You need the <ACL Number> created in 11. Create the Access Control List (ACL) and the <Primary Tunnel Interface> and <Backup Tunnel Interface> created in 10. Create the Tunnel Interfaces.

    Enter the following commands:

    route-map <Route Map Name> permit 1
         match ip address <ACL Number>
         set interface <Primary Tunnel Interface> <Backup Tunnel Interface>

    You need the <Route Map Name> for 13. Configure Network Address Translation (NAT).

    Close
  • Configure NAT on the WAN and LAN interfaces. You need the <Route Map Name> created in 12. Define the Route Map.

    Enter the following commands:

    interface <WAN Interface>
         description $ES_WAN$
         ip address 10.96.19.244 255.255.255.0
         ip access-group <ACL Number> in
         ip access-group <ACL Number> out
         ip nat outside
         ip virtual-reassembly in
         duplex auto
         speed auto
        interface <LAN Interface>
         ip address 172.17.0.128 255.255.255.0
         ip access-group <ACL Number> in
         ip access-group <ACL Number> out
         ip nat inside
         ip virtual-reassembly in
         ip policy route-map <Route Map Name>                   
    Close
  • The IP SLA monitor is used to provide failover between the two tunnels. If the primary tunnel fails, the backup tunnel is used automatically. Ensure the IP address used for VPN monitoring is reachable.

    The following IP SLAs are defined as ip sla 1 and ip sla 2. In your configuration, you can optionally define different values for the tracking object and the IP SLA operation ID numbers (e.g., track 3 ip sla 3). The ID numbers show in the output of the show track <ID> command when later tracking the IP SLA status.

    You need the <Primary Tunnel Interface> and <Backup Tunnel Interface> created in 10. Create the Tunnel Interfaces.

    If you use PAC files to forward traffic through the tunnel, ensure that you use different Global ZIA Public Service Edge IP addresses for IP SLA monitoring and your PAC files. Using the same Global ZIA Public Service Edge IP addresses causes the PAC files to send all packets through the same tunnel regardless of the tunnel interface state.

    Enter the following commands:

    config IP SLA
        track 1 ip sla 1 state
         delay down 180 up 180
        track 2 ip sla 2 state
         delay down 180 up 180
        ip route <Primary Global ZIA Public Service Edge IP Address> 255.255.255.255 <Primary Tunnel Interface> permanent
        ip route <Backup Global ZIA Public Service Edge IP Address> 255.255.255.255 <Backup Tunnel Interface> permanent
        ip sla 1
         http raw http://<Primary Global ZIA Public Service Edge IP Address>:80
         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
         threshold 300
         timeout 5000
        ip sla schedule 1 life forever start-time now
        ip sla 2
         http raw http://<Backup Global ZIA Public Service Edge IP Address>:80
         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
         threshold 300
         timeout 5000
        ip sla schedule 2 life forever start-time now
        ip sla reaction-configuration 1 react rtt threshold-value 300 1 threshold-type consecutive 3
        ip sla reaction-configuration 2 react rtt threshold-value 300 1 threshold-type consecutive 3 

    If you want to configure VPN monitoring for more tunnels, see additional Global ZIA Public Service Edge IP addresses.

    Close

Troubleshooting

In the ZIA Admin Portal, you can go to Analytics > Tunnel Insights to see data as well as monitor the health and status of your configured IPSec VPN tunnels. To learn more, see About Insights and About Insights Logs.

On the Cisco router, you can use the following troubleshooting commands while setting up the tunnels. Note the values in green while troubleshooting.

  • Use the show crypto isakmp sa command to troubleshoot Phase 1 of the tunnel. The response shows an organization’s gateway with IKE configured correctly. The status value is ACTIVE.

    The <Customer IP> is the customer's public IP address on the WAN interface of the ISR.

    IPv4 Crypto ISAKMP SA
        dst 	                  src                 state              conn-id       status
        <Primary VPN Hostname>	  <Customer IP>       QM_IDLE            2012          ACTIVE
        <Backup VPN Hostname>     <Customer IP>       AG_INIT_EXCH       2011          ACTIVE
        IPv6 Crypto ISAKMP SA   
    Close
  • Use the show crypto ipsec sa command to troubleshoot Phase 2 of the tunnel. The response shows an organization’s gateway with IKE configured correctly. Ensure that some packets are encapsulated and decapsulated for the primary and secondary tunnel and that the inbound and outbound ESP SAs have an ACTIVE status. This indicates that traffic is flowing through the tunnel.

    The <Corporate Public IP> is the IP address on the router from which the IPSec tunnel is established.

    interface: <Primary Tunnel Interface>	 
            Crypto map tag: Tunnel1-head-0, local addr: <Corporate Public IP> 
        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: <Primary VPN Hostname> 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.: <Corporate Public IP>, remote crypto endpt.: <Primary VPN Hostname>
        path mtu <MTU>, ip mtu <MTU>, 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: <Backup Tunnel Interface>	 
            Crypto map tag: Tunnel2-head-0, local addr: <Corporate Public IP> 
        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: <Backup VPN Hostname> 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.: <Corporate Public IP>, remote crypto endpt.: <Backup VPN Hostname>
        path mtu <MTU>, ip mtu <MTU>, 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:
    Close
  • Use the show track <ID> command to track the IP SLA status. The IP SLA reachability status indicates the tunnel monitoring results. Reachability is Down indicates that the tunnel monitoring failed, while Reachability is Up indicates that the tunnel monitoring is successful.

    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
    Close
  • Use the show ip sla statistics command to view the 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
    Close
  • Use the show crypto session command to simulate a fail condition for the primary tunnel and verify that a failover to the backup tunnel occurs. If the failover is successful, the backup tunnel has an UP-ACTIVE session status and the primary tunnel has a DOWN-NEGOTIATING session status.

    Crypto session current status
        Interface: <Backup Tunnel Interface>
        Session status: UP-ACTIVE
        Peer: <Backup VPN Hostname> port 500
         IKEv1 SA: local <Corporate Public IP>/500 remote <Backup VPN Hostname>/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: <Primary Tunnel Interface>
        Session status: DOWN-NEGOTIATING
        Peer: <Primary VPN Hostname> port 500
         IKEv1 SA: local <Corporate Public IP>/500 remote <Primary VPN Hostname>/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 
    Close
Related Articles
Understanding IPSec VPNsConfiguring an IPSec VPN TunnelAbout VPN CredentialsAdding VPN CredentialsImporting VPN Credentials from a CSV FileIPSec VPN Configuration Guide for Cisco ASA 55xxIPSec VPN Configuration Guide for Cisco 881 ISRIPSec VPN Configuration Guide for Juniper SRXIPSec VPN Configuration Guide for Juniper SSG 20IPSec VPN Configuration Guide for FortiGate FirewallIPSec VPN Configuration Guide for Palo Alto Networks FirewallIPSec VPN Configuration Guide for SonicWall TZ 350Locating the Hostnames and IP Addresses for ZIA Public Service Edges