VPN Training & Configuration - Highighted

Zscaler
Training Manual
Technical Support Engineers

VPN Configuration
Administrator Course Copyright Notice
Copyright Notice
Information in this document is subject to change without notice. The names of companies, products,
people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent
any real individual, company, product, or event, unless otherwise noted. Complying with all applicable
copyright laws is the responsibility of the user.
Zscaler and the Zscaler logo are registered trademarks of Zscaler, Inc. in the United States. The Cloud
Security Company is claimed as a trademark by Zscaler. All other brand and product names are
trademarks or registered trademarks of their respective owners.
Specifications and other information may be subject to change without notice. Portions of this manual
have been reprinted in part or in whole from other copyrighted sources owned by Zscaler.
Copyright 2014 Zscaler, Inc. All rights reserved.
No part of this publication may be reproduced, photocopied, stored in a retrieval system, or transmitted
without the express prior written consent of Zscaler, Inc.
Content Development: Zscaler Training Development Team
Released: January 2014 v1.00

Training Manual Table of Contents
Table of Contents
1.1 > INTRODUCTION ..............................................................................................................................................2
1.2 > IPSEC GOALS .................................................................................................................................................2
1.2.1 Ensuring Confidentiality .......................................................................................................................3
1.2.2 Verifying Packet Integrity .....................................................................................................................3
1.2.3 Authenticating Peers ............................................................................................................................3
1.3 > IPSEC PROTOCOLS ..........................................................................................................................................3
1.3.1 IKE ........................................................................................................................................................4
1.3.2 Diffie-Hellman ......................................................................................................................................5
1.4 > PHASE 1 .......................................................................................................................................................5
1.4.1 Main Mode ...........................................................................................................................................5
1.4.2 Aggressive Mode ..................................................................................................................................7
1.5 > PHASE 2 .......................................................................................................................................................8
1.5.1 Basics ...................................................................................................................................................8
1.5.2 Dead Peer Detection ............................................................................................................................8
2.1 > ZSCALER SETTINGS ..........................................................................................................................................9
2.1.1 Prerequisites ........................................................................................................................................9
2.1.2 Adding VPN Credentials .......................................................................................................................9
2.1.3 Creating a New Location ....................................................................................................................10
2.1.4 Select Zscaler VPN concentrator ........................................................................................................10
2.2 > CUSTOMER NETWORK EQUIPMENT CONFIG ........................................................................................................11
2.3 > WORKING WITH ZSCALER IPSEC ......................................................................................................................11
2.3.1 Only two SPI per customer IP address ................................................................................................12
2.3.2 IPSec Tunnel doesnt come up ............................................................................................................12
3.1 > UNDERSTAND ZSCALER COMPONENTS...............................................................................................................13
3.1.1 Architecture........................................................................................................................................13
3.1.2 Capturing network traffic ...................................................................................................................13
3.2 > READ IPSEC STATUS ......................................................................................................................................15
3.2.1 Phase 1 ...............................................................................................................................................15
3.2.2 Phase 2 ...............................................................................................................................................15
3.3 > ESCALATING AN IPSEC CONNECTIVITY ISSUE .......................................................................................................16
4.1 > CONFIGURATION EXAMPLE: CISCO ASA 5505 ...................................................................................................17
4.1.1 Configuring the Firewall .....................................................................................................................17
4.1.2 Configuring the Interfaces..................................................................................................................17
4.1.3 Defining Security Parameters.............................................................................................................20
4.1.4 Troubleshooting .................................................................................................................................23
4.2 > CONFIGURATION EXAMPLE: JUNIPER SSG5 .......................................................................................................27
4.2.2 Configuring the Firewall .....................................................................................................................29
4.2.3 Configuring the Interfaces..................................................................................................................29
4.2.4 Configuring Tunnel Interfaces ............................................................................................................30
4.2.5 Defining IKE Parameters ....................................................................................................................32
4.2.6 Configuring Policy-Based Routing ......................................................................................................33
4.2.7 Creating Policies .................................................................................................................................38
4.3 > PRE-SHARED KEY (PSK) VPN BETWEEN JUNIPER SRX 210/ SRX 220 AND ZVPN: ..................................................39
4.3.1 Steps to be done on Juniper SRX 220 .................................................................................................39
4.3.2 Overall config for the Juniper SRX-220 ...............................................................................................44
4.4 > PRE-SHARED KEY (PSK) VPN BETWEEN CISCO 881 AND 2821 ROUTER AND ZVPN: ................................................50
4.4.1 Steps to be done on Cisco 881 and 2821 Router ................................................................................50
4.4.2 Overall config for the Cisco 881 router: .............................................................................................53
4.4.3 Debugging Cisco 881 VPN tunnel .......................................................................................................58
Copyright 2012 Zscaler, Inc. All rights reserved.

Training Manual GRE Configuration
Chapter 1: VPN Configuration

Chapter Objectives
After completing this chapter, you should be able to
Understand basics of VPN configuration
Understand Zscaler specifics
Configure VPN on Cisco, Juniper equipments
Copyright 2014 Zscaler, Inc. All rights reserved. Page | 1
For Internal Use Only

VPN Configuration Training Manual
1.1 > Introduction

Using IPsec is a common way to securely transport traffic between one point to another point in the
network. You can use IPsec VPNs to forward your HTTP and HTTPS traffic from your corporate network
and branch offices to the Zscaler Security Cloud. IPsec VPNs require no configuration on PCs or laptops,
like PAC files. IPsec VPNs also support tunneling from dynamic IP address branches or from locations
behind a NAT firewall.
Notes: Zscaler supports only HTTP, HTTPS, SMTP, FTP over HTTP/HTTPS and native FTP (passive) traffic through IPsec
VPNs. When the Security Cloud receives traffic it does not support, it converts the source address to a public address, with
source NAT, and then sends it out to the Internet with no control over this traffic. Zscaler recommends that you send only
HTTP/HTTPS/SMTP/ FTP over HTTP/HTTPS and native FTP (passive) traffic to the Security Cloud.
IPsec (Internet protocol security) is a suite of protocols that provide network-layer security to a VPN
(virtual private network). A VPN is a virtual network that provides a secure communication path between
two peers in a public network. The peers can be two hosts, a remote host and a network gateway, or the
gateways of two networks, such as the gateway of your corporate network and a ZEN (Zscaler
Enforcement Node) in the Security Cloud.
IPsec provides the following types of protection:
Confidentiality: Ensures that data cannot be read by unauthorized parties.
Integrity: Verifies that data was not modified during transit.
Authentication: Verifies the identity of the peers.
As shown in Figure 1, IPsec provides a number of options for applying each type of protection. The peers
in the IPsec VPN use a negotiation process called IKE (Internet Key Exchange) to define the security
mechanisms they will use to protect their communications. IKE has two phases.
In the first phase, the peers define the security parameters they will use to communicate in the
second phase. This collection of security parameters is called a security association (SA).
In the second phase, the peers define the SA that they will use to protect the actual data exchange.
Figure 1: IPsec VPN
1.2 > IPSec Goals
Page | 2 Copyright 2012 Zscaler, Inc. All rights reserved.

Training Manual VPN Configuration
1.2.1 Ensuring Confidentiality

IPsec uses algorithms such as DES (Data Encryption Standard) and AES (Advanced Encryption standard) to
encrypt IP packets. These algorithms use symmetric key cryptography to provide encryption.
In this type of cryptography, the peers use the same key to encrypt and decrypt packets. When peer A
sends a packet to peer B, it first encrypts the data by dividing it into blocks, and then uses the key and
data blocks to perform multiple rounds of cryptographic operations. When peer B receives the packet, it
uses the same key and performs the same operations in reverse order to decrypt the data.
AES now supersedes DES and 3DES because it has a larger block size and key length. AES uses a 128-bit
block size and keys with 128, 192 and 256 bits. DES uses a block size of 64 bits and a key length of 56 bits.
Though 3DES has a larger key size, which is 168 bits, it still has the same block size.
1.2.2 Verifying Packet Integrity

IPsec provides authentication and integrity protection through an HMAC (hash message authentication
code) algorithm, such as MD5 (Message Digest Algorithm-5) or SHA (Secure Hash Algorithm). This type of
algorithm generates a hash (also referred to as a message digest) from the message and a key known to
both peers. When peer A sends a message to peer B, it generates the hash and adds it to the packet it
sends to peer B. When peer B receives the packet, it uses the shared key to generate the hash and
verifies the authenticity and integrity of the packet when the two hashes match.
SHA-1 and SHA-2 are generally considered more secure than MD5 because they generate a larger hash.
MD5 generates a 128-bit hash, SHA-1 generates a 160-bit hash, and SHA-2 is a set of four algorithms
whose names refer to the size of the hashes they produce, that is SHA2-224, SHA2-256, SHA2-384, and
SHA2-512.
1.2.3 Authenticating Peers

IPsec peers can use the following methods to authenticate each other:
PSK (pre-shared keys): This type of authentication uses a key that the peers agree on beforehand.
The key, also known as a secret, is a text string similar to a password. Peer A uses the pe-shared key
and additional data to generate a hash value. Peer B uses the same key and additional data to
generate a hash value. Peer B authenticates peer A when the two hash values match.
Digital Certificates: Each peer has a digital certificate that contains a public key. In this type of
authentication, peer A generates a hash value and encrypts the hash with its private key. The
encrypted hash is its digital signature. Peer A then sends the certificate with its digital signature to
peer B. Peer B generates another hash and uses the public key to decrypt the digital signature. Peer
B compares the decrypted digest with the digest it generated to verify that that the source of the
message is peer A. RSA is typically used as the digital signature algorithm.
External Authentication: This adds another layer of protection by authenticating the actual users. An
external server, such as a Kerberos server or AD server is used to authenticate the user by their user
ID and password. It is used in addition to one of the other authentication methods.
1.3 > IPsec Protocols

IPsec has two main protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). The
IPsec peers determine which protocol they will use to encode the data packets in phase 2 of the IKE

negotiations. The selected protocol then uses the algorithms and authentication method defined in the
IPsec SA to encode the data packets.
AH provides authentication and integrity protection through a keyed hash algorithm described in
Verifying Packet Integrity. ESP encrypts IP packets as described in Ensuring Confidentiality. The earlier
version of ESP did not provide authentication and integrity protection, so most IPsec implementations
used AH and ESP. But since the current version of ESP can also use a keyed hash algorithm to verify the
authenticity and integrity of packets, most IPsec implementations use ESP, but not necessarily AH.
ESP can operate in either of two modes: transport mode or tunnel mode. Figure 2 illustrates an IP packet
in transport mode and in tunnel mode. As shown in the illustration, ESP adds a header, a trailer, and if
authentication is used, an authentication section at the end. The ESP header contains an SPI (Security
Parameter Index) value, which is a unique identifier, and a sequence number. The ESP trailer contains
fields such as additional bytes for padding and the padding length.
As shown in Figure 2, in transport mode, ESP encrypts the data payload and ESP trailer. It uses the
original IP header with the original source and destination IP addresses. In implementations that involve
communications from or to a gateway, the source and/or destination IP addresses need to be changed to
the gateway IP addresses. Since transport mode does not alter the IP header, this mode is used
specifically for host-to-host communications.
In tunnel mode, ESP encapsulates the entire packet, including the original IP header. It adds a new IP
header that lists the IPsec peers as the source and destination of the packet. ESP tunnel mode is used in
VPNs that include at least one gateway, because the gateway address can be specified as the source
and/or destination in the new IP header.
Figure 2: ESP Modes
1.3.1 IKE
IKE provides a secure way to establish the IPsec services that the peers use to protect their
communications. As described in an earlier section, IKE has two phases. In the first phase, the peers

negotiate the parameters for a secure communication channel through which they negotiate the
parameters for the second phase. This first set of parameters is referred to as the IKE SA. This SA is bi-
directional, so only one SA is established for both directions of traffic.
In the second phase, the peers negotiate the parameters for the actual exchange of IP packets. The
second set of parameters is referred to as the IPsec SA. The IPsec SA is uni-directional, therefore one SA
is established for each connection.
1.3.2 Diffie-Hellman
Diffie-Hellman is a method for peers to generate a shared key in a secure manner, without having to
exchange shared secrets in the first place. Diffie-Hellman specifies group numbers that correspond to a
key length and an encryption generator type. During the IKE negotiations, the peers agree on the Diffie-
Hellman group number that they use to generate the shared key. For more information on Diffie-
Hellman, refer to RFC 2631, Diffie-Hellman Key Agreement Method.
1.4 > Phase 1

Phase 1 can operate in either main mode or aggressive mode. In main mode, there are three pairs of
message exchanges, and in aggressive mode, there are three messages.
1.4.1 Main Mode

The following figure illustrates the three sets of messages exchanged in main mode:

Figure 3: IKE Phase 1 Main Mode

In the first pair of messages, the peers negotiate the following
o The encryption algorithm
o The keyed hash algorithm
o The authentication method
o The Diffie-Hellman group that the peers use to generate a shared key.
o SA lifetime, which is the time period that an SA is valid. Peers must establish a new SA when it
expires.
In the second pair of messages, the peers exchange the Diffie-Hellman keys.
In the third pair of messages, the two peers authenticate each other.
Because Main mode uses the IP address as part of the exchange for identification, it cannot be used in
configuration where the IP address of the peer may change.

1.4.2 Aggressive Mode

The following figure illustrates the three messages exchanged in aggressive mode:
Figure 4: IKE Phase 1 Aggressive Mode

In the first message, peer A sends the security parameters, its Diffie-Hellman key, a pseudo-random
number and its IKE identity to peer B.
In the second message, peer B confirms the security parameters, sends its Diffie-Hellman key, a
pseudo-random number, its IKE identity and authentication parameters.
In the third message, peer A sends its authentication parameters.
Aggressive Mode is useful when the IP address of the remote device is not known beforehand.
Note: For Phase 1, Zscaler supports AES or 3DES for the encryption algorithm, and SHA-1 or MD5 for the
authentication algorithm. The Zscaler recommended algorithms are AES with SHA-1.

1.5 > Phase 2

Phase 2 establishes an SA for each direction of traffic. It operates in only one modeQuick modewhich
uses three messages. The negotiations in phase 2 are protected by the IKE SA.
1.5.1 Basics
The Phase 2 negotiations are similar to those in Phase 1, wherein the peers negotiate security
parameters that includes the encryption and keyed hashed algorithms, and authentication method.
Additionally, in this phase, the peers negotiate the IPsec protocol to be applied to the IP packets. They
determine whether to use AH, ESP and AH, or ESP. As stated earlier, most VPNS today use ESP.
After the IPsec SA is established, the peers then exchange the IP packets using the security parameters
defined in the IPsec SA.
Note: For Phase 2, Zscaler supports Null Encryption or AES for the encryption algorithm and MD5 for the
authentication algorithm. The Zscaler recommended algorithms are Null Encryption with MD5.
1.5.2 Dead Peer Detection

Dead peer detection is a method that is used to detect if an IKE peer is offline. When this method is used,
the peers do not periodically exchange keep alive messages. Instead, a peer requests proof that the
other peer is online only when it needs to send traffic. Dead peer detection decreases the number of
messages needed to determine if a peer is alive. Each peer defines its own dead peer detection interval,
which is implementation specific. For more information, refer to RFC 3706, A Traffic-Based Method of
Detecting Dead Internet Key Exchange (IKE) Peers.

Chapter 2: Configuring an IPsec

VPN
This section provides guidelines for configuring an IPsec VPN tunnel between the gateway of your
corporate network and a ZEN in the Security Cloud. Zscaler recommends configuring two separate VPNs
to two different ZENs for high availability. If the primary IPsec VPN tunnel or if an intermediate
connection goes down, all traffic is then rerouted through the backup IPsec tunnel to the secondary ZEN,
as shown in Figure 5. Note that you can also configure a third tunnel where NAT is performed on the
non-Web traffic that is sent directly to the Internet.
Figure 5: Configuring a VPN to the Zscaler Security Cloud
2.1 > Zscaler settings

2.1.1 Prerequisites
Before you start configuring the firewall and the Security Service, you must setup VPN credentials on
Zscaler console. VPN credentials identifier can be based on IP address or FQDN. If IP based is choosen,
this IP must be provisioned to customer account before being able to create the corresponding VPN
credential.
2.1.2 Adding VPN Credentials

To create the VPN credential and define the shared secret:
Navigate to Administration -> VPN Credentials.
Click Edit, and then click Add New VPN Credentials.
On the Site-to-Site IPsec VPN Credentials page, do the following:
o Select the VPN IP Address or FQDN checkbox and click Select. Select the preprovisioned IP
address or the username. This is the IP address that was given to Zscaler beforehand.
o Enter the pre-shared key abc. in the text box and confirmation box.
o Click Done to exit.

Click Save and Activate Now.
2.1.3 Creating a New Location

To create a new location and assign the VPN credentials to that location:
Navigate to Administration -> Internet Gateways & SSL.
Click Edit, and then click Add New Location.
In the Internet Gateway Location page, do the following:
o Enter the location name NW Branch for example.
o Click Select beside VPN Credentials.
o Move the VPN credentials you created by choosing it from the Available VPN Credentials column
to the Selected VPN Credentials column, and then click Done.
o Click Done to exit the Internet Gateway Location page.
Click Save and Activate Now.
2.1.4 Select Zscaler VPN concentrator

In order to connect to Zscaler VPN concentrator, customers can either use Zscaler dedicated and
dynamic hostname: vpn.<cloudname>.net (ie: vpn.zscalertwo.net) or one of the static hostname
available from the online help under Firewall Configuration section.
You can find the full list of VPN enabled nodes by looking at the server list on Zadmin. Please see next
section for further information.

2.2 > Customer network equipment config

This section lists the IPsec parameters that Zscaler supports. Note that when there are multiple options,
the values in bold are the recommended settings.
Please note that Zscaler only supports IKEv1 protocol today. As a result, you cant establish VPN Tunnel
from a Checkpoint Firewall as it only supports IKEv2 protocol. IKEv2 should be implemented with 4.2
release.
IKE Phase 1
Mode: Aggressive mode when the authentication method is PSK and the FQDN of the peer is used to
identify it. Main mode when the authentication method PSK and the peer has a static IP address.
Encryption algorithm: AES-128, 3DES, DES
Authentication Algorithm: SHA1-128
Diffie-Hellman Group 2
SA Lifetime: 24 hours
Lifebytes: Unlimited
Authentication: Pre-shared keys, digital signature using RSA, external authentication and pre-shared
keys, or external authentication and RSA
NAT-T : NAT-T is supported if the device initiating the IPsec VPN is behind another firewall or router
performing NAT.
NAT Keep alive interval : 20 secs
Enable dead-peer-detection keepalives ( timeout is 20 secs and max retry 5)
IKE Phase 2
Mode: Quick mode
Encryption and Authentication Algorithms: NULL/MD5, AES-128/MD5
Diffie-Hellman Group 2
SA Lifetime: 8 hours
Lifebytes: Unlimited
Perfect Forward Secrecy (PFS) option is disabled. This option enables each IPsec SA to generate a
new shared secret through a Diffie-Hellman exchange. This option is not recommended for Zscaler
VPNs.
2.3 > Working with Zscaler IPSec

This section is about things you have to know about Zscaler IPSec implementation.

2.3.1 Only two SPI per customer IP address

Today, Zscaler IPSec VPN only supports one single SA session and two SPI (Phase2 session) per customer
IP address.
If the customer network equipment tries to establish several SA session, only the first one will be taken
into account. It can lead into multiple problems.
Customer has to update his configuration in order to make sure only one SA session is established to
Zscaler.
It is a common known problem with ASA Firewall and complex routing ACL rules.
This limitation will be raised with 4.2 revision.
2.3.2 IPSec Tunnel doesnt come up

2.3.2.1 Wrong service IP
Customer used to mix up Zscaler common service VIP with the dedicated VPN service VIP. The VPN IPSec
Tunnel can only come up on the VPN VIP. In order to check if customer is using the appropriate VIP you
will have to review the network equipment configuration or take a packet capture on the Zscaler node
that they are trying to connect to.
Troubleshooting: Take a packet capture on the active VPN IPSec which is suppose to receive traffic and
filter based on the router IP address.
Solution: Provide the correct VPN VIP service to the customer and update customer router configuration
accordantly.
2.3.2.2 Unassociated VPN Credential

A common mistake is to try to bring up an IPSec Tunnel when the VPN Credential is not associated with a
location. In such case, the tunnel will never come up as our node is not able to verify the customer
identity. The connection will stop on the phase1 negotiation.
Solution: associate the desired VPN Credential with a location.

Chapter 3: Troubleshooting
3.1 > Understand Zscaler components

Every enabled datacenter can be easily found from Zscaler Admin by looking at the server list. If the
datacenter has a ZVPN node, it means that customers can establish a VPN Tunnel to this datacenter.
While this ZVPN service is sharing the same management IP address as SME nodes, it runs on a dedicated
service IP with a dedicated VIP. ZVPN service is only working in an Active / Standby mode, the SMLB node
doesnt handle VPN traffic. The following screenshot shows up Paris DC on zscalertwo.net cloud. The VPN
VIP appears in Yellow:
3.1.1 Architecture
Our IPSec VPN terminator is based on racoon IKE project. It has been adapted, patched and improved for
Zscaler needs. The VPN service is tied to the BSD system.
This service receives traffic on the MGMT interface and forwards the unencrypted traffic through a GRE
Tunnel to the Datacenter VIP service. Racoon service is listening on the MGMT interface on a dedicated
CARP VIP.
Internet -> Racoon -> (over GRE) SMLB -> SME
Every VPN IPSec enabled system has one racoon service running on the BSD system. Racoon
configuration file is available at the following folder: $ZSINSTANCE/conf/racoon/
3.1.2 Capturing network traffic

Network traffic can be captured before and after the VPN session is established. IPSec protocol is using
different set of proto numbers and UDP ports. Here are most common used ports:
Standard ports used
o ip proto 50 for IPSec Encapsulating Security Protocol (ESP) traffic
o ip proto 51 for IPSec Authentication Header (AH) traffic
o UDP port 500 for Internet Key Exchange (IKE) negotiation traffic
With NAT Traversal (NAT-T) active

o UDP port 500 for Internet Key Exchange (IKE) negotiation traffic
o UDP port 4500 for IPSec Encapsulating Security Protocol (ESP) traffic
3.1.2.1 Capturing the encrypted traffic

This packet capture has to be executed on the management interface with the standard tcpdump. You
can filter on the IPSec traffic only with the following command:
For IKE traffic: sudo tcpdump -i igb0 -n udp port 500
For all encrypted traffic: sudo tcpdump -i igb0 -n ip proto 50 or udp port 4500
Here is an example of captured traffic:
IKE Traffic:
[support@cdg1b ~]$ sudo tcpdump -i igb0 -n udp port 500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 96 bytes
13:43:47.866514 IP 77.242.202.241.500 > 109.1.158.158.500: isakmp: phase 1 ? agg
13:43:47.901425 IP 80.11.24.198.500 > 77.242.202.241.500: isakmp: phase 2/others ? inf[E]
Encrypted traffic:
[support@cdg1b ~]$ sudo tcpdump -i igb0 -n ip proto 50 or udp port 4500
listening on igb0, link-type EN10MB (Ethernet), capture size 96 bytes
13:37:18.335781 IP 109.1.168.99 > 77.242.202.241: ESP(spi=0x096b0bd7,seq=0x75aa), length 76
13:37:18.336002 IP 109.6.237.25 > 77.242.202.241: ESP(spi=0x026b09f5,seq=0xae65), length 64
13:37:18.336115 IP 109.1.158.23 > 77.242.202.241: ESP(spi=0x0fb39e29,seq=0x97ad), length 64
13:37:18.336254 IP 77.242.202.241 > 109.1.158.104: ESP(spi=0x75f584d3,seq=0x5ad1), length 64
13:37:18.336340 IP 82.234.143.192 > 77.242.202.241: ESP(spi=0x08eed1b3,seq=0x1a3c8), length 64
13:37:18.336390 IP 77.242.202.241 > 109.1.168.99: ESP(spi=0x9bbc7d26,seq=0x6f81), length 76
13:37:18.336474 IP 77.242.202.241 > 109.1.158.155: ESP(spi=0xa7392a51,seq=0x54aa), length 64
13:37:18.336493 IP 77.242.202.241 > 109.1.158.155: ESP(spi=0xa7392a51,seq=0x54ab), length 64
13:37:18.336514 IP 77.242.202.241 > 109.1.168.94: ESP(spi=0xd658a914,seq=0x9d63), length 64
3.1.2.2 Capturing the decrypted traffic

Once the VPN Session is established, the VPN IPSec traffic will be depapsuled and forwarded to the local
VIP through a GRE Tunnel.
Decapsuled traffic can be seen thanks to the enc0 virtual interface. It shows the phase2 SPI ID with the
original traffic originally sent by the user. Here is the command to run in order to capture this traffic:
sudo ifconfig enc0 up && sudo tcpdump -i enc0 -n
Here is an example:
[support@cdg1b ~]$ sudo ifconfig enc0 up && sudo tcpdump -i enc0 -n
Password:
tcpdump: WARNING: enc0: no IPv4 address assigned
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 96 bytes
13:50:50.932153 (authentic,confidential): SPI 0xa7e6fc24: IP 77.242.202.241 > 109.1.155.185: IP 8.26.202.126.80 > 10.128.178.52.59059: .
929886449:929887749(1300) ack 3767748762 win 2071 (ipip-proto-4)
13:50:50.932191 (authentic,confidential): SPI 0x01160868: IP 193.248.137.215 > 77.242.202.241: IP 10.159.192.55.53033 > 23.38.69.109.80: .
ack 3673323134 win 16575 (ipip-proto-4)
13:50:50.932374 (authentic,confidential): SPI 0xd4cbd00c: IP 77.242.202.241 > 109.1.159.35: IP 213.163.79.36.80 > 10.203.42.61.53295: .
13:50:50.932397 (authentic,confidential): SPI 0xd4cbd00c: IP 77.242.202.241 > 109.1.159.35: IP 213.163.79.36.80 > 10.203.42.61.53295: .
13:50:50.932430 (authentic,confidential): SPI 0x051c32d1: IP 109.1.154.191 > 77.242.202.241: IP 10.135.65.44.52781 > 173.194.67.94.443: .
ack 2298985668 win 16575 (ipip-proto-4)

13:50:50.932610 (authentic,confidential): SPI 0x09334f6a: IP 89.224.187.12 > 77.242.202.241: IP 10.227.224.125.58686 > 176.34.108.101.80: .
ack 3329942478 win 255 <nop,nop,timestamp 2083790 558647981> (ipip-proto-4)
13:50:50.932628 (authentic,confidential): SPI 0x048e9b11: IP 146.255.170.58 > 77.242.202.241: IP 172.23.90.163.62903 > 157.56.252.38.443:
P 4046759419:4046759936(517) ack 409380733 win 64 (ipip-proto-4)
3.2 > Read IPSec status

3.2.1 Phase 1
In multi-instance mode the VPN service is always hosted in the first instance folder.
If a Phase1 SA session has been successfully established with the node, it will show up with the following
command:
racoonctl show-sa isakmp
Here is an example of this command execution on a multi-instance environment. Note that racoons unix
socket has to be passed in argument in order to get this information.
[root@cdg1a /sc/cdg1a1-sme]# bin/racoonctl -s log/racoon.sock show-sa isakmp | grep 176.31.125.142
176.31.125.142.500 190016f95d2593b3:92ce8c13729cfa2a 2014-01-03 14:00:56
The time value in bold corresponds to the SA creation time.

Here is the log for a successful established Phase 1 session:
[root@cdg1a /sc/cdg1a1-sme]# tail -10000 log/racoon.log | grep 176.31.125.142
2014-01-03 14:00:56: INFO: respond new phase 1 negotiation: 77.242.202.241[500]<=>176.31.125.142[500]
2014-01-03 14:00:56: [176.31.125.142] INFO: received INITIAL-CONTACT
2014-01-03 14:00:56: INFO: ISAKMP-SA established 77.242.202.241[500]-176.31.125.142[500] spi:190016f95d2593b3:92ce8c13729cfa2a
3.2.2 Phase 2
When a phase2 session is successfully established with Zscaler, two SPI are created (one in each
direction). The following command will return all attributes corresponding to this session.
[root@cdg1a /sc/cdg1a1-sme]# bin/racoonctl -s log/racoon.sock show-sa esp | grep -A11 176.31.125.142

77.242.202.241 176.31.125.142
esp mode=tunnel spi=107096725(0x06622a95) reqid=0(0x00000000)
E: null
A: hmac-md5 50326846 e8629374 1dd83e10 0b531696
seq=0x00000025 replay=4 flags=0x00000000 state=mature
created: Jan 3 14:00:56 2014 current: Jan 3 14:01:23 2014
diff: 27(s) hard: 28800(s) soft: 28800(s)
last: Jan 3 14:01:18 2014 hard: 0(s) soft: 0(s)
current: 12612(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 37 hard: 0 soft: 0
sadb_seq=386 pid=28929 refcnt=2
ZVPN (E) userid=8803974 compid=8261166 locid=8470359
176.31.125.142 77.242.202.241
esp mode=tunnel spi=202610788(0x0c139864) reqid=0(0x00000000)
E: null
A: hmac-md5 c1af9cf5 6ba93d75 be980287 f034b3c7
seq=0x0000002e replay=4 flags=0x00000000 state=mature
created: Jan 3 14:00:56 2014 current: Jan 3 14:01:23 2014
diff: 27(s) hard: 28800(s) soft: 28800(s)
last: Jan 3 14:01:18 2014 hard: 0(s) soft: 0(s)
current: 4426(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 46 hard: 0 soft: 0
sadb_seq=385 pid=28929 refcnt=1
ZVPN (E) userid=8803974 compid=8261166 locid=8470359
Here is a short description of each attribute:

SPI = session ID
State = status of the connection. Possible values: mature, dying (about to be refreshed), larval, dead

E = negotiated encryption algorithm

A = negotiated signature algorithm
Created = creation time of this SPI
Current = number of bytes seen on for this SPI
ZVPN = Zscaler specific information. It contains the location ID, organization ID and VPN credential ID
which has been used to establish this VPN session.
If this command shows more than 2 mature SAs, the communication may fail as Zscaler only supports 2
SAs (one in each directory) at a time prior to 4.2.
Here is the log for a successful established Phase 2 session:
2014-01-03 14:00:56: [176.31.125.142] INFO: received INITIAL-CONTACT

2014-01-03 14:00:56: INFO: respond new phase 2 negotiation: 77.242.202.241[500]<=>176.31.125.142[500]
2014-01-03 14:00:56: INFO: no policy found, try to generate the policy : 176.31.125.142/32[500] 77.242.202.241/32[500] proto=any dir=in
2014-01-03 14:00:56: INFO: IPsec-SA established: ESP/Tunnel 77.242.202.241[500]->176.31.125.142[500] spi=202610788(0xc139864)
2014-01-03 14:00:56: INFO: IPsec-SA established: ESP/Tunnel 77.242.202.241[500]->176.31.125.142[500] spi=107096725(0x6622a95)
3.3 > Escalating an IPSec connectivity issue

In order to escalate an IPSec connectivity issue, you will have to collect the following information in
addition to default information:
Full configuration of the customer equipment with the constructor name, model and software
version.
Capture the tunnel status for phase 1 and phase 2 when the problem happens
A log extraction matching the customer gateway IP address
A packet capture on the mgmt interface taken when the problem occures
Chapter 4: Configuration Examples

This section provides examples of how to configure VPNs from a firewall or router to ZENs in the Zscaler
Security Cloud. Each example uses a different firewall or router as the originating peer.
Zscaler supports most firewall or router vendors except CheckPoint which only supports IKEv2 protocol.
Zscaler supports IKEv1 protocol only, IKEv2 is going to be implemented in 4.2.
Note: Zscaler recommends that you use the solutions in the configuration examples when you configure VPN tunnels to
the Security Cloud. Using different hardware or software versions may result in an interruption of your Web traffic.
This section includes the following configuration examples:

Configuration Example: Cisco ASA 5505
Configuration Example: Juniper SSG5
Configuration Example: Juniper SRX 210/ SRX 220

Configuration Example: Cisco 881 router

For the complete list of commands for the firewall or router in the configuration examples, see Appendix
A.
4.1 > Configuration Example: Cisco ASA 5505

This example illustrates how to configure two IPsec VPN tunnels from a Cisco ASA 5505 firewall to two
ZENs in the Security Cloud.
As shown in Figure 8, the corporate office sends its traffic to Ethernet 0/1 through 0/7 in the internal
network. These interfaces are in VLAN2 and have a security level of 100. They forward the traffic to
Ethernet 0/0, which then sends Web traffic through the VPN tunnel to the Security Cloud and performs
NAT on the non-Web traffic that it sends to the Internet.
In this example, the peers are using a pre-shared key for authentication. DPD is enabled so the firewall
can detect if one VPN goes offline and move the web traffic to the backup VPN.
Figure 6: VPN between a Cisco ASA 5505 and the Security Cloud
4.1.1 Configuring the Firewall

This section provides sample commands for configuring two IPsec VPN tunnel interfaces on a Cisco ASA
5505 firewall running ASA version 8.2.5. Refer to the Cisco documentation for information about the
commands.
Perform the following tasks to configure the firewall:
1. Configure the interfaces on the firewall. For more information, see Configuring the Interfaces.
2. Define the IKE policy For more information, see Defining Security Parameters.
4.1.2 Configuring the Interfaces

Configure the interfaces as follows:
Ethernet 0/0:
o Security-level: 0

o Obtains its IP address through DHCP

o Outgoing tunnel interface
o VLAN 2
Ethernet 0/1 through Ethernet 0/7:
o Security-level: 100
o VLAN 1
The MTU (maximum transmission unit) on the ingress and egress ports: 1300
Specify routes to the ZEN interfaces: 10.10.104.71 and 10.10.104.235
Configuration:
interface Ethernet0/0
switchport access vlan 2
!
!
!
!
!
!
!
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address dhcp setroute
!
ftp mode passive

object-group service not-http-https tcp

port-object range 1 finger
port-object range 444 65535
port-object range 81 442
object-group protocol DM_inline
protocol-object icmp
protocol-object udp
object-group service DM_INLINE_SERVICE_1
service-object icmp echo
service-object icmp echo-reply
service-object tcp eq www
service-object tcp eq https
service-object udp eq domain
object-group service DM_INLINE_SERVICE_2
service-object icmp echo
service-object icmp echo-reply
service-object tcp eq www
service-object tcp eq https
service-object udp eq domain
access-list inside_nat_outbound extended permit tcp any any object-group not-http-https
access-list inside_nat_outbound extended permit object-group DM_inline any any
access-list outside_cryptomap_1 remark VPN traffic
access-list outside_cryptomap_1 extended permit object-group DM_INLINE_SERVICE_1 any any
inactive
access-list outside_cryptomap_2 extended permit object-group DM_INLINE_SERVICE_2 any any
access-list outside_cryptomap extended permit ip 192.168.1.0 255.255.255.0 any
access-list outside_access_in extended permit ip 192.168.1.0 255.255.255.0 any
access-list test extended permit tcp any any eq www
access-list test extended permit tcp any any eq https
access-list test extended permit udp any any eq domain
access-list test extended permit icmp any any
pager lines 24
logging asdm informational
mtu inside 1300
mtu outside 1300
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 1 interface

nat (inside) 1 access-list inside_nat_outbound

access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 10.10.120.1 1
route outside 10.10.104.0 255.255.255.0 10.10.120.1 1
4.1.3 Defining Security Parameters

In this section, you define an IKE policy for Phase 1, a transform set for Phase 2 and a crypto-map.
The IKE policy specifies the parameters used during the IKE negotiations. In this example, use the
following attributes:
Authentication method: PSK
Encryption algorithm: 3DES
Authentication algorithm: MD5
Diffie -Hellman Group: 2
SA Lifetime: 86400 seconds
The transform set specifies a set of IPsec protocols and algorithms. In this example, use the IPsec
transform set crypto ipsec transform-set test esp-aes esp-md5-hmac.
The crypto-map binds the properties of the IPsec configuration. In this example, create the crypto-map
outside_map with the following attributes:
IKE Phase 1 mode: aggressive
Connection type: originate-only
Peer IP addresses: 10.10.104.71 and 10.10.104.235
Tunnel group: 10.10.104.71 with its type set to ipsec-l2l
Group-policy: GroupPolicy1 with vpn-tunnel-protocol set to IPsec
PSK: abc
Disable peer-id validation
Configuration:
crypto ipsec transform-set test esp-aes esp-md5-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto ipsec security-association lifetime seconds 1800

crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 set connection-type originate-only
crypto map outside_map 1 set peer 10.10.104.71 10.10.104.237 10.10.104.235
crypto map outside_map 1 set transform-set test
crypto map outside_map 1 set security-association lifetime seconds 3600
crypto map outside_map 1 set phase1-mode aggressive
crypto map outside_map 2 match address outside_cryptomap
crypto map outside_map 2 set connection-type originate-only
crypto map outside_map 2 set peer 10.10.104.71 10.10.104.235
crypto map outside_map 2 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA
ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-
DES-MD5
crypto map outside_map 2 set phase1-mode aggressive
crypto map outside_map interface outside
crypto isakmp identity address
crypto isakmp enable inside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
dhcpd address 192.168.1.5-192.168.1.36 inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
group-policy GroupPolicy1 internal
group-policy GroupPolicy1 attributes

vpn-tunnel-protocol IPSec
tunnel-group TunnelGroup1 type ipsec-l2l
tunnel-group TunnelGroup1 ipsec-attributes
pre-shared-key *****
peer-id-validate nocheck
tunnel-group 10.10.104.71 type ipsec-l2l
tunnel-group 10.10.104.71 general-attributes
default-group-policy GroupPolicy1
tunnel-group 10.10.104.71 ipsec-attributes
tunnel-group 10.10.104.235 type ipsec-l2l
tunnel-group 10.10.104.235 general-attributes
default-group-policy GroupPolicy1
tunnel-group 10.10.104.235 ipsec-attributes

4.1.4 Troubleshooting
Following are some sample commands that you can use to monitor and troubleshoot the VPNs.
View the Phase 1 SA

ciscoasa# show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.10.104.235

Type : L2L Role : initiator
Rekey : no State : AM_ACTIVE
View the Phase 2 SA

ciscoasa# show crypto ipsec sa
interface: outside
Crypto map tag: outside_map, seq num: 2, local addr: 10.10.120.34

local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: 10.10.104.235
#pkts encaps: 161, #pkts encrypt: 161, #pkts digest: 161

#pkts decaps: 223, #pkts decrypt: 223, #pkts verify: 223
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 161, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 10.10.120.34, remote crypto endpt.: 10.10.104.235
path mtu 1300, ipsec overhead 74, media mtu 1500

current outbound spi: 0B27AE21
current inbound spi : 294C420E
inbound esp sas:

spi: 0x294C420E (692863502)

transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 12288, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373810/1592)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x0B27AE21 (187149857)
IV size: 16 bytes
Anti replay bitmap:
0x00000000 0x00000001
View the Route Table

ciscoasa# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 10.10.120.1 to network 0.0.0.0
S 10.10.104.0 255.255.255.0 [1/0] via 10.10.120.1, outside

C 10.10.120.0 255.255.255.0 is directly connected, outside
C 192.168.1.0 255.255.255.0 is directly connected, inside
d* 0.0.0.0 0.0.0.0 [1/0] via 10.10.120.1, outside

Clear the Phase 1 Tunnel

ciscoasa# clear crypto isakmp sa
Active SA: 1
Total IKE SA: 1
1 IKE Peer: 10.10.104.71

Type : user Role : initiator
Rekey : no State : AM_WAIT_MSG2
ciscoasa#
ciscoasa#
Active SA: 1
Total IKE SA: 1
1 IKE Peer: 10.10.104.235

Active SA: 1
Total IKE SA: 1
1 IKE Peer: 10.10.104.235

Clear the Phase 2 Tunnel

ciscoasa# clear crypto ipsec sa
ciscoasa# show crypto ip

There are no ipsec sas

There are no ipsec sas

interface: outside
Crypto map tag: outside_map, seq num: 2, local addr: 10.10.120.34

current_peer: 10.10.104.235

#pkts not compressed: 120, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
path mtu 1300, ipsec overhead 74, media mtu 1500

current outbound spi: 063CA185
current inbound spi : 0692415C
inbound esp sas:

spi: 0x0692415C (110248284)
IV size: 16 bytes
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:

spi: 0x063CA185 (104636805)

IV size: 16 bytes
Anti replay bitmap:
0x00000000 0x00000001
ciscoasa# show crypto isa

Active SA: 1
Total IKE SA: 1
1 IKE Peer: 10.10.104.235

4.2 > Configuration Example: Juniper SSG5

This example illustrates how to configure two IPsec VPN tunnels from a Juniper SSG5 firewall to two ZENs
in the Security Cloud.
As shown in Figure 10, the internal traffic of the corporate office is in the Trust zone. The WAN port
Ethernet 0/0 is in the Untrust zone. It sends Web traffic through the VPN tunnel to the Security Cloud
and performs NAT on the non-Web traffic that it sends to the Internet.
In this example, the peers are using a pre-shared key for authentication and the FQDN of the peer.
DPD and VPN monitoring must be enabled so the firewall can detect if one VPN goes offline and move
the web traffic to the other VPN. We are also configuring a route-based VPN where we are creating two
tunnels and inserting them as the default routes in the routing table.

Figure 7: VPN between a Juniper SSG5 and the Security Cloud
4.2.1.1 Prerequisites
Before you start configuring the Security Service and the firewall, you must send Zscaler the following
information:
The FQDN of the peer. In this example, it is abc@test.net.
The PSK. In this example, the PSK is abc.

4.2.2 Configuring the Firewall

This section describes how to log in to the user interface of a Juniper SSG5 firewall running version 6.0.0
r3 and configure two IPsec VPN tunnel interfaces. Refer to the Juniper documentation for additional
information about the user interface.
Log in to the Juniper SSG5 and complete the following tasks:
3. Configure the interfaces and bind them to the Trust and Untrust zones. For more information, see
Configuring the Interfaces.
4. Configure the VPN tunnel interfaces. For more information, see Configuring the Tunnel Interfaces.
5. Configure the IKE parameters. For more information, see Defining IKE Parameters.
6. Configure policy-based routing. For more information, see Configuring Policy-Based Routing.
7. Define the policies. For more information, see Creating Policies.
4.2.3 Configuring the Interfaces

Configure the following interfaces:
Egress port is Ethernet 0/0 in the Untrust Zone.
Bgroup0 LAN and wireless ports in the Trust Zone
Tunnel interfaces in the Untrust Zone
The following step describes how to configure the tunnel.1 interface. Follow the same steps to configure
the tunnel.2 interface.
Navigate to Network > Interfaces > List , and select New Tunnel IF, complete the following, and then
click OK:
o Tunnel Interface Name: tunnel.1
o Zone (VR): Untrust (trust-vr)
o Select Unnumbered and from the Interface drop-down, choose ethernet0/0 (trust-vr)
o Set the MTU to 1300.
The ports are configured as shown in the following figure:

Figure 8: Configured Ports on the Juniper SSG5
4.2.4 Configuring Tunnel Interfaces

Create a static route to the Zscaler ZENs via the gateway learned on Ethernet 0/0.
Navigate to Network > Routing > Destination > trust-vr and click New. Enter the following, and then
click OK:
o IP Address/Netmask: 0.0.0.0/0
o Click Gateway and complete the following:
Interface: ethernet0/0
Gateway IP Address: 10.10.104.0/24
The following steps describe how to create an IPsec VPN tunnel using the tunnel.1 interface. Follow the
same steps to configure the tunnel.2 interface.
8. Navigate to VPNs > AutoKey Advanced > Gateway and click New.
9. Complete the following, as shown in Figure 12:
o Gateway Name: vpn-235
o Click Remote Gateway, select Static IP Address and enter 10.10.104.235. This is the IP address
of the Zscaler ZEN.

Figure 9: Gateway Configuration

10. Click Advanced and complete the following, as shown in Figure 13:
o Preshared Key: abc
o Local ID: abc@test.net
o Security Level: Click Custom and from the Phase-1 Proposal drop-down, select pre-g2-aes128-
sha.
o Mode (Initiator): Click Aggressive
o Click Enable NAT-Traversal
o Keepalive Frequency: Enter 5 seconds
o Peer Status Detection: Select DPD and set the following:
Threshold: 5
Interval: 5
Retry: 5
11. Click Return, and then click OK.

Figure 10: AutoKey Advanced Configuration
4.2.5 Defining IKE Parameters

The following step describes how to specify the AutoKey IKE parameters for the tunnel.1 interface.
Follow the same steps to configure the tunnel.2 interface.
12. Navigate to VPNs > AutoKey IKE and click New.
13. Complete the following:
o Select Remote Gateway and do the following:
Click Predefined and select vpn-235.
Outgoing Interface: Select ethernet0/0.
14. Click Advanced and complete the following, as shown in the following figure:
o Security Level: Select User Defined (Custom) and from the Phase-2 Proposal drop-down, select
g2-esp aes128-md5
o Select Replay Protection
o Bind to: Click Tunnel Interface and select tunnel.1
o Select VPN Monitor and complete the following:
Source Interface: ethernet 0/0
Destination IP: Enter any IP address that is always reachable, such as the SME IP address
10.10.104.70
15. Select Optimized
16. Select Rekey

Figure 11: IKE Phase 2 Configuration
4.2.6 Configuring Policy-Based Routing

Configure policy-based routing to ensure that the branch can send its outbound traffic from the Trust
zone to the Untrust zone, and out through one of the newly created tunnel interfaces.
17. Navigate to Network > Routing > PBR > Extended ACL.
18. Select New to create an extended ACL and add an entry for TCP traffic on port 80. Complete the
following and click OK:
o Extended ACL ID: 1
o Sequence No. 50
o Destination Port: 80~80
o Protocol: TCP
19. Click Add Seq. No, complete the following to add an entry for TCP traffic on port 443, and then click
OK:
o Sequence No. 60
o Protocol: TCP
20. Click Add Seq. No and complete the following to add an entry for ICMP traffic, and then click OK:
o Sequence No. 70
o Protocol: ICMP
21. Click Add Seq. No and complete the following to add an entry for UDP traffic on port 53, and then
click OK:

o Sequence No. 80
o Protocol: UDP
The following figure shows the completed extended ACL:
Figure 12: Extended ACL

Create a match group named test to match the newly created extended ACL.
22. Navigate to Network > Routing > PBR > Match Group and click New.
23. Complete the following and click OK:
o Match Group Name: test
o Seq. No: 10
o Extended ACL: Select 1.
The following figure shows the completed match group:

Figure 13: Match Group

Create an action group named test2, and set the next hop to tunnel.1 and tunnel.2.
24. Navigate to Network > PBR > Action Group and click New to create an action group.
25. Complete the following and click OK to add an entry for tunnel.1:
o Action Group Name: test2
o Seq. No: 30
o Route To: Click Interface and select tunnel.1.
26. Complete the following and click OK to add an entry for tunnel.2:
o Action Group Name: test2
o Seq. No: 10
o Route To: Click Interface and select tunnel.2.
The following figure shows the completed action group:

Figure 14: Action Group

Create a policy test2 and specify the match group test and action group test2.
27. Navigate to Network > Routing > PBR > Policy and click New.
o Policy Name: test2
o Seq. No: 10
o Match Group: Select test.
o Action Group: Select test2.
The following figure shows the complete policy:
Figure 15: test2 Policy

Bind the test2 policy to the Trust interfaces.

29. Navigate to Network > Routing > PBR > Policy Binding.
30. Do the following to bind the test 2 policy to the wireless0/0 interface:
o Click N/A in the Policy Name field to the right of wireless0/0.
o In the Policy Binding dialog, click Enable and from the Policy drop-down, select test2. Click OK to
exit the dialog.
31. Do the following to bind the test 2 policy to the bgroup0 interface:
o Click N/A in the Policy Name field to the right of bgroup0.
o In the Policy Binding dialog, click Enable and from the Policy drop-down, select test2. Click OK to
exit the dialog.
The following figure shows the completed policy binding list.
Figure 16: Policy Binding List

4.2.7 Creating Policies

Create two policies. Create one policy that allows traffic from the Trust to the Untrust zone and another
policy that allows traffic from the Untrust to the Trust zone.
32. Navigate to Policy > Policies.
33. Select the following, and then click New:
o From drop-down: Select Trust
o To drop-down: Select Untrust
o Source Address: Any
o Destination Address: Any
o Service: Any
o Action: Permit
Create the same policy from the Untrust zone to the Trust zone. The following figure displays the
completed policies.
Figure 17: Policies

After you have completed the configuration, you can monitor the status of the tunnel by navigating to
VPNs > Monitor Status, as shown in the following figure.
Figure 18: Monitoring the VPN Tunnels

You can also test the tunnel by browsing from the Trust zone (through the wireless or ebgroup0 LAN
ports) to any site, such as www.google.com. You are then required to log in to the Zscaler Cloud before
you can access the site.
4.3 > Pre-Shared Key (PSK) VPN between Juniper SRX

210/ SRX 220 and ZVPN:
In this test we have created two IP based PSK VPN from Juniper SRX 220 firewall to the Zscaler Cloud for
redundancy. Also VPN Monitoring is enabled so that if one VPN goes down then the route is marked as
down by the SRX 220 and traffic goes thru the secondary tunnel. Make sure the JunOS version is 10.4 and
above for this test.
4.3.1 Steps to be done on Juniper SRX 220
We will be creating 2 VPN tunnels to the Zscaler cloud using IP address based PSK credentials using lds
as PSK. Two tunnels are created to make sure that if one fails the traffic can go to other tunnel. In the
design we are making sure that DPD is enabled and also VPN Monitoring is turned on. In this example we
have used Route Based VPN where we are creating two tunnels and inserting them as the default route
in the routing table. Detailed steps are shown below:

Interface ge-0/0/0 is configured in Untrust Zone. This is Internet port which is getting IP address
using DHCP.
Interfaces ge-0/0/1 to ge-0/0/07 are configured in Trust Zone. All of them are part of trust vlan 0.
Tunnels are created using st0 interface. Unit0 and unit1 sub interfaces are configured in st0. Two
default routes are configured using st0.0 and st0.1.
Config corresponding to above steps is shown below:
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
dhcp;
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/2 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/3 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/4 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/5 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/6 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/7 {
unit 0 {
vlan {

members vlan-trust;
}
}
}
}
st0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
}
}
st1 {
unit 0 {
family inet;
}
}
vlan {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop [ st0.0 st0.1 ];
route 10.10.104.0/24 next-hop 10.10.120.1;
}
}
Now security configuration will be started as shown below:
Create ike proposal named as test with attributes:
o authentication-method set to pre-shared-keys
o dh-group set to group2
o authentication-algorithm set to sha1
o encryption-algorithm set to aes-128-cbc
o lifetime set to 86400 seconds.
Now create ike-policy say ike-policy1 with:
o Mode aggressive
o Pre-shared key: lds
o Proposal is test.
Now create two ike gateways say ike-gate and ike-gate-secondary with:
o Ike-policy set to ike-policy1
o Address set to the ZVPN Node IPsec address e.g. 10.10.104.71 and
10.10.104.235 in this case.
o Enable dead-peer-detection (DPD)
o Set external-interface to the internet port e.g. in this test it is set to ge-
0/0/0
Overall ike config portion is shown below:

ike {
proposal test {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;

lifetime-seconds 86400;
}
policy ike-policy1 {
mode aggressive;
proposals test;
pre-shared-key ascii-text "$9$rYllMXdVYoZj"; ## SECRET-DATA
}
policy test {
mode aggressive;
proposals test;
pre-shared-key ascii-text "$9$iHfz9Cu1Eyp0"; ## SECRET-DATA
}
gateway ike-gate {
ike-policy ike-policy1;
address 10.10.104.71;
dead-peer-detection {
always-send;
interval 20;
threshold 5;
}
nat-keepalive 20;
external-interface ge-0/0/0;
}
gateway ike-gate-secondary {
address 10.10.104.235;
always-send;
interval 20;
threshold 5;
}
nat-keepalive 20;
}
}
Create IPsec related config as mentioned below
Enable VPN monitoring with interval 30 seconds and threshold as 4.

Create IPsec proposal say test with attributes :
Protocol set to esp
Authentication-algorithm set to hmac-sha1-96
Lifetime set to 1800
Create IPsec policy say vpn-policy1 with standard proposal-set.
Create two vpns say ike-vpn and ike-vpn-secondary with attributes:
o Bind-interface st0.0 and st0.1 respectively
o Set the df bit
o Enable vpn-monitor with source-interface set to internet port i.e. ge-
0/0/0 and destination should be an IP address which should be always
available thru the SME .e.g. service IP address of the sme e.g.
10.10.104.70 in this case.
o establish-tunnels should be set to immediately
o set ike gateway to ike-gate and ike-gate-secondary respectively
o set idle time to 4000
o set ipsec-policy to vpn-policy1
Here is the IPsec portion of the security config:
ipsec {

vpn-monitor-options {
interval 30;
threshold 4;
}
proposal test {
protocol esp;
authentication-algorithm hmac-sha1-96;
}
policy vpn-policy1 {
proposal-set standard;
}
vpn ike-vpn {
bind-interface st0.0;
df-bit set;
vpn-monitor {
optimized;
source-interface ge-0/0/0;
destination-ip 10.10.104.70;
}
ike {
gateway ike-gate;
idle-time 4000;
ipsec-policy vpn-policy1;
}
establish-tunnels immediately;
}
vpn ike-vpn-secondary {
df-bit set;
vpn-monitor {
optimized;
}
ike {
gateway ike-gate-secondary;
idle-time 4000;
}
}
}
Now configure nat part of the config to make sure that is traffic is not going thru
the tunnel interface then it is natted out:
nat {
source {
rule-set nat-out {
from zone trust;
to zone untrust;
rule interface-nat {
match {
source-address 192.168.0.0/16;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}

4.3.2 Overall config for the Juniper SRX-220
root# run show configuration

## Last commit: 2012-05-12 03:49:41 UTC by root
version 10.4R4.5;
system {
root-authentication {
encrypted-password "$1$kR7I/O3B$ZezY.j09/sk6IWYJWcEVm."; ## SECRET-DATA
}
name-server {
10.35.3.41;
10.35.3.42;
}
services {
ssh {
root-login allow;
}
telnet;
xnm-clear-text;
web-management {
http {
interface [ vlan.0 ge-0/0/1.0 ge-0/0/0.0 ];
}
https {
system-generated-certificate;
interface vlan.0;
}
}
dhcp {
router {
192.168.1.1;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.2 high 192.168.1.254;
}
propagate-settings ge-0/0/0.0;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 5;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
dhcp;
}
}
}
ge-0/0/1 {
unit 0 {
vlan {
members vlan-trust;
}
}
}

}
ge-0/0/2 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/3 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/4 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/5 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/6 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
ge-0/0/7 {
unit 0 {
vlan {
members vlan-trust;
}
}
}
}
st0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
}
}
st1 {
unit 0 {
family inet;
}
}
vlan {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop [ st0.0 st0.1 ];

route 10.10.104.0/24 next-hop 10.10.120.1;

}
}
protocols {
stp;
}
security {
ike {
proposal test {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
}
policy ike-policy1 {
mode aggressive;
proposals test;
pre-shared-key ascii-text "$9$rYllMXdVYoZj"; ## SECRET-DATA
}
policy test {
mode aggressive;
proposals test;
pre-shared-key ascii-text "$9$iHfz9Cu1Eyp0"; ## SECRET-DATA
}
gateway ike-gate {
address 10.10.104.71;
always-send;
interval 20;
threshold 5;
}
nat-keepalive 20;
}
gateway ike-gate-secondary {
address 10.10.104.235;
always-send;
interval 20;
threshold 5;
}
nat-keepalive 20;
}
}
ipsec {
vpn-monitor-options {
interval 30;
threshold 4;
}
proposal test {
protocol esp;
authentication-algorithm hmac-sha1-96;
}
policy vpn-policy1 {
proposal-set standard;
}
vpn ike-vpn {
df-bit set;
vpn-monitor {
optimized;
}
ike {
gateway ike-gate;
idle-time 4000;
}
}
vpn ike-vpn-secondary {
df-bit set;
vpn-monitor {

optimized;
}
ike {
gateway ike-gate-secondary;
idle-time 4000;
}
}
}
nat {
source {
rule-set nat-out {
from zone trust;
to zone untrust;
rule interface-nat {
match {
source-address 192.168.0.0/16;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
zones {
security-zone trust {
address-book {
address local-net 192.168.0.0/16;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0;
}
}
security-zone untrust {
screen untrust-screen;
system-services {
ike;
}
}
interfaces {
ge-0/0/0.0 {

system-services {
dhcp;
tftp;
all;
}
}
}
}
}
security-zone vpn {
address-book {
address remote-net 0.0.0.0/0;
}
interfaces {
st0.0;
st0.1;
}
}
}
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
policy any-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone vpn {
policy vpn-tr-vpn {
match {
source-address local-net;
destination-address remote-net;
application any;
}
then {
permit;
}
}
}
from-zone vpn to-zone trust {
policy vpn-vpn-tr {
match {
source-address remote-net;
destination-address local-net;
application any;
}
then {
permit;
}
}
}
}
flow {
tcp-mss {
ipsec-vpn {
mss 1300;
}
}
}
}
vlans {
vlan-trust {
vlan-id 3;
l3-interface vlan.0;
}

[edit]
4.3.2.1 Debugging Juniper SRX220 tunnel
To list the routing table to make sure that st0.0 and st0.1 routes are present in the routing table:
show route
inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:28:59

via st0.0
> via st0.1
[Access-internal/12] 00:28:33
> to 10.10.120.1 via ge-0/0/0.0
10.10.104.0/24 *[Static/5] 00:28:33
> to 10.10.120.1 via ge-0/0/0.0
10.10.120.0/24 *[Direct/0] 00:28:33
> via ge-0/0/0.0
10.10.120.43/32 *[Local/0] 00:28:33
Local via ge-0/0/0.0
192.168.1.0/24 *[Direct/0] 00:28:45
> via vlan.0
192.168.1.1/32 *[Local/0] 00:28:59
Local via vlan.0
To list the Phase-2 tunnel execute the command show security ipsec security-associations
show security ipsec security-associations

Total active tunnels: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 10.10.104.71 500 ESP:3des/sha1 1a39db6d 1763/ unlim U root
>131073 10.10.104.71 500 ESP:3des/sha1 c362105 1763/ unlim U root
<131074 10.10.104.235 500 ESP:3des/sha1 7d034970 3241/ unlim U root
>131074 10.10.104.235 500 ESP:3des/sha1 933e2cd 3241/ unlim U root
To list the Phase-1 tunnel execute the command show security ike security-
associations
show security ike security-associations

Index Remote Address State Initiator cookie Responder cookie Mode
762537 10.10.104.71 UP d4fe08bb5caa5236 8c2e7176846414f6 Aggressive
762540 10.10.104.235 UP 16c40476f1b054b9 a3fba378716129fa Aggressive
To clear IPsec and ike sa use the respective clear commands as shown
below:
root>
show security ipsec security-associations
<131073 10.10.104.71 500 ESP:3des/sha1 3491a9ba 2758/ unlim U root
>131073 10.10.104.71 500 ESP:3des/sha1 6840028 2758/ unlim U root
root> clear security ipsec security-associations index 131073
root> show security ipsec security-associations


<131073 10.10.104.71 500 ESP:3des/sha1 d4dd1b0c 3590/ unlim U root

>131073 10.10.104.71 500 ESP:3des/sha1 85115fd 3590/ unlim U root
Similarly use command clear security isakmp command to clear Phase-1 tunnels
4.4 > Pre-Shared Key (PSK) VPN between Cisco 881 and
2821 Router and ZVPN:
In this test we have created two FQDN based VPN from Cisco 881 and 2821 Router to the Zscaler Cloud
for redundancy. Also VPN Monitoring is enabled so that if VPN tunnel going down can be detected as
soon as possible and the route is marked as down by the Cisco IOS and traffic goes thru the secondary
tunnel. As 881 and 2821 support Cisco IOS so the commands to create the tunnel configuration are same
on both platform.
4.4.1 Steps to be done on Cisco 881 and 2821 Router

We will be creating 2 VPN tunnel to the Zscaler cloud using PSK credentials with FQDN as lds@test.net
and Pre shared key as lds. Two tunnels are created to make sure that if one fails the traffic can go to
other tunnel. In the design we are making sure that DPD is enabled, IPsec Fragmentation is enabled, MTU
is set correctly to 1300 on tunnel interfaces and VPN Monitoring is turned on. For head end side
generally reverse route feature is also recommended
(http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09
186a0080739e7c.pdf ). In this example we are using have used Route Based VPN where we are
creating two tunnel and inserting them as the default route in the routing table. Syntax of the command
for Ipsec tunnel is same on 881 and 2821 router as both of them support same Cisco IOS Versions.
However in this test we did not use thatDetailed steps are shown below:
881 router is an access device with 1 WAN port(fa4) and multiple lan( fa0,1,2,3) ports.
Clinet devices like laptop etc are getting address via DHCP pool configured on the 881 router. WAN
port i.e. fa4 is getting address via DHCP from the service provider.
Natting is enabled on the WAN port to make sure that traffic going outbound from the LAN ports is
getting natted before going to internet.
Using the access-list only tcp traffic for port 80, 443 and icmp traffic are tunneled via the VPN tunnel.
Steps to create the tunnel:
Create isakmp (Phase-1 tunnel policy say policy1) with following attributes:
o Encryption set to aes
o Authentication set to pre-share
o Group-2
o Lifetime 14400

encr aes

group 2
lifetime 14400
Enable DPD i.e. dead peer detection using following command:
crypto isakmp keepalive 10 periodic
Enable nat keepalive using following command:
crypto isakmp nat keepalive 20
Now create isakmp peer address as shown below with following attributes set:
o Set aggressive mode and the password for that
o Set user-fqdn e.g. lds@test.net
crypto isakmp peer address 10.10.104.71

set aggressive-mode password lds
set aggressive-mode client-endpoint user-fqdn lds@test.net
!
Now create the ipsec transform-set say test for Phase-2 as shown below:
crypto ipsec transform-set myset esp-3des esp-md5-hmac
Enable ipsec fragmentation after the encryption:
crypto ipsec fragmentation after-encryption
Now create ipsec profile say VTI as shown below with following attributes:
o Set transform-set to the test
o Set pfs group to group2
o Set security-association(sa) lifetime to 14400
o Set sa idle-time to 14400
crypto ipsec profile VTI

set security-association lifetime seconds 14400

set security-association idle-time 14400

set transform-set myset
set pfs group2
Now create a Tunnel interface say 400 for one Zscaler gateway and 500 for another Zscaler ZVPN
gateway as shown below with attributes:
Mtu set to 1400
o Tcp-mss set to 1300
o Tunnel-source set to the WAN port i.e. fastethernet4 (fa4)
o Tunnel mode set to ipsec ipv4
o Tunnel destination should be Zscaler ZVPN IP addresss
o Tunnel protection ipsec profile set to VTI
o Ip address should be derived from fa4
interface Tunnel400
ip unnumbered FastEthernet4
ip mtu 1400
ip tcp adjust-mss 1300
tunnel source FastEthernet4
tunnel mode ipsec ipv4
tunnel destination 10.10.104.71
tunnel protection ipsec profile VTI
interface Tunnel500
no ip address
ip mtu 1400
Now create access-list to separate the http/https/ftp and icmp traffic which will be sent to the tunnel
Create a route-map for above traffic and set the next-hop for that as the above tunnels
access-list 101 permit tcp any any eq www
access-list 101 permit tcp any any eq 443
access-list 101 permit icmp any any
access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any any eq ftp-data
!
!
!
!
route-map zscaler-tunnel permit 10
match ip address 101
set interface Tunnel400 Tunnel500
Now create nat on the fa4 interface as shown below:
interface FastEthernet4
description $ES_WAN$
ip address dhcp client-id FastEthernet4 hostname 10.35.3.41
ip access-group 80 in
ip access-group 80 out
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$
no ip address


!
interface Vlan2
ip address 10.65.199.129 255.255.255.128
ip nat inside
ip policy route-map zscaler-tunnel
!
!
ip nat inside source list NAT interface FastEthernet4 overload
Now enable VPN Monitoring using IP SLA as shown below.

Make sure the IP address which is used for monitoring is reachable as
long as the Node is reachable.
One simplest IP address which can be used is the ZEN Service address.
Make sure this address is routable thru the tunnel only:
track 400 ip sla 400 reachability

!
ip sla 400
icmp-echo 10.10.104.70
ip sla schedule 400 life forever start-time now

ip sla 500
icmp-echo 10.10.104.80
ip route 10.10.104.70 255.255.255.255 Tunnel400 permanent

4.4.2 Overall config for the Cisco 881 router:
VPN-test#show run
Building configuration...
Current configuration : 10626 bytes

!
! Last configuration change at 02:24:36 UTC Sat May 19 2012 by skumar
!
version 15.1
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VPN-test
!
boot-start-marker
boot-end-marker
!
!
logging buffered 4096
!
no aaa new-model
memory-size iomem 10
crypto pki token default removal timeout 0
!
crypto pki trustpoint tti
revocation-check crl
!
crypto pki trustpoint TP-self-signed-2721864363

enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2721864363
revocation-check none
!
!
crypto pki certificate chain tti
crypto pki certificate chain TP-self-signed-2721864363
certificate self-signed 01
3082022B 30820194 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 32373231 38363433 3633301E 170D3132 30353138 32333538
30335A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 37323138
36343336 3330819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
8100B562 8F07F3C9 27A51798 A200FB7B 8831144D 079464DF E5CE2E69 7031F3A7
DFBF74A0 BB20E910 057F95DC 5384059C 2FDAB310 AFA9CA61 B745CA98 C987A664
E0FF66C0 11D0C069 F8BDE9C5 25291420 68A5316E 1B2153B7 2541C1EB 526F227B
B8E2F74B FAE66C82 B7F8347C 108DE12B 6824C1B2 7FF930A3 4A8650C8 0C5A99D2
277B0203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF 301F0603
551D2304 18301680 1423C3EE 7927E46A FA1516B0 CDA87259 032CF389 7E301D06
03551D0E 04160414 23C3EE79 27E46AFA 1516B0CD A8725903 2CF3897E 300D0609
2A864886 F70D0101 04050003 81810038 ACE3269E 1E006AC8 F3C2CD23 FFF4195B
81EE3586 81892F66 88CD9CB4 4BC74747 68119E52 EE3664DA E38F3122 DCD08985
200FF48D 74D754A0 05DE46FC FD9645B0 85F134F4 6060798B A2079359 8B80F979
3C52396A E10A7347 2ACFDE8D C4DF117B 78CBDE1E EEB18972 E6F7D103 A8E90A7A
E3992466 B720B237 B5AA0A06 B2950E
quit
ip source-route
!
!
!
ip dhcp excluded-address 10.65.199.129
!
ip dhcp pool ccp-pool
import all
network 10.65.199.128 255.255.255.128
default-router 10.65.199.129
dns-server 10.10.104.23
lease 0 2
!
!
ip cef
ip domain name yourdomain.com
ip name-server 10.10.104.23
no ipv6 cef
!
!
license udi pid CISCO881-K9 sn FCZ1510C25F
!
!
username root privilege 15 secret 5 $1$tNw1$LDdmzCh/UNWcL.odwKkyD1
username sachin privilege 15 secret 5 $1$lXn2$gxtDItkOXiDydXTA0Netu.
username skumar privilege 15 secret 5 $1$ZnCs$B/0DfujHTS6.Kr/uIIYbq.
!
!
!
!
!
!
!
!
encr aes
group 2
lifetime 14400
!
encr aes
group 2
crypto isakmp keepalive 10 periodic
crypto isakmp nat keepalive 20
!
set aggressive-mode password C9dYfsdtd8
set aggressive-mode client-endpoint user-fqdn MHVPN-000010@lds.org

!
!
set aggressive-mode password t35tu5er
set aggressive-mode client-endpoint user-fqdn testuser@sdev.com
!
!
!
set aggressive-mode password test
set aggressive-mode client-endpoint user-fqdn test@skumar.com
!
set aggressive-mode password hello
set aggressive-mode client-endpoint user-fqdn hello@test.net
!
!
!
set aggressive-mode password test
set aggressive-mode client-endpoint user-fqdn test@skumar.com
!
set aggressive-mode password letmein
set aggressive-mode client-endpoint ipv4-address 152.26.228.202
!
set aggressive-mode password testpassword
!
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
crypto ipsec fragmentation after-encryption
!
crypto ipsec profile VTI
set security-association lifetime seconds 14400
set pfs group2
!
crypto ipsec profile VTI1
!
!
!
!
!
!
!
interface Loopback1000
ip address 4.4.4.1 255.255.255.255
!
interface Tunnel1
no ip address
!
interface Tunnel200
ip mtu 1500


shutdown
!
interface Tunnel202
no ip address
ip mtu 1400
!
interface Tunnel300
ip mtu 1400
shutdown
!
interface Tunnel400
ip mtu 1400
!
interface Tunnel500
no ip address
ip mtu 1400
!
!
!
!
!
description $ES_WAN$
ip address dhcp client-id FastEthernet4 hostname 10.35.3.41
ip nat outside
duplex auto
speed auto
!
interface Vlan1
description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$
no ip address
!
interface Vlan2
ip address 10.65.199.129 255.255.255.128
ip nat inside
ip policy route-map zscaler-tunnel
!
ip forward-protocol nd

ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source list NAT interface FastEthernet4 overload
ip route 0.0.0.0 0.0.0.0 Tunnel400 track 12
ip route 0.0.0.0 0.0.0.0 10.10.120.1
ip route 10.10.100.153 255.255.255.255 Tunnel400
ip route 10.10.100.210 255.255.255.255 Tunnel400
ip route 65.55.206.203 255.255.255.255 Tunnel400
!
ip access-list extended NAT
permit ip 10.65.199.0 0.0.0.255 any
deny ip any any
!
ip sla 2
icmp-echo 173.194.79.94
frequency 500
timeout 3000
threshold 2000
ip sla 400
icmp-echo 10.10.104.70
ip sla 500
icmp-echo 10.10.104.80
logging esm config
logging trap debugging
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 80 permit any
access-list 100 permit ip any any
access-list 101 permit tcp any any eq www
access-list 101 permit tcp any any eq 443
access-list 101 permit icmp any any
access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any any eq ftp-data
access-list 120 permit ip any any
access-list 180 permit ip 10.0.0.0 0.255.255.255 any
no cdp run
!
!
!
!
route-map zscaler-tunnel permit 10
match ip address 101
set interface Tunnel400 Tunnel500
!
banner exec ^C
% Password expiration warning.
-----------------------------------------------------------------------
Cisco Configuration Professional (Cisco CP) is installed on this device

and it provides the default username "cisco" for one-time use. If you have
already used the username "cisco" to login to the router and your IOS image
supports the "one-time" user option, then this username has already expired.
You will not be able to login to the router with this username after you exit
this session.
It is strongly suggested that you create a new username with a privilege level
of 15 using the following command.
username <myuser> privilege 15 secret 0 <mypassword>
Replace <myuser> and <mypassword> with the username and password you
want to use.
-----------------------------------------------------------------------
^C
banner login ^C
-----------------------------------------------------------------------

Cisco Configuration Professional (Cisco CP) is installed on this device.

This feature requires the one-time use of the username "cisco" with the
password "cisco". These default credentials have a privilege level of 15.
YOU MUST USE CISCO CP or the CISCO IOS CLI TO CHANGE THESE
PUBLICLY-KNOWN CREDENTIALS
Here are the Cisco IOS commands.
username <myuser> privilege 15 secret 0 <mypassword>

no username cisco
Replace <myuser> and <mypassword> with the username and password you want
to use.
IF YOU DO NOT CHANGE THE PUBLICLY-KNOWN CREDENTIALS, YOU WILL

NOT BE ABLE TO LOG INTO THE DEVICE AGAIN AFTER YOU HAVE LOGGED OFF.
For more information about Cisco CP please follow the instructions in the
QUICK START GUIDE for your router or go to http://www.cisco.com/go/ciscocp
-----------------------------------------------------------------------
^C
!
line con 0
login local
no modem enable
line aux 0
line vty 0 4
password askjans
login local
length 0
transport input telnet ssh
!
end
4.4.3 Debugging Cisco 881 VPN tunnel
To dump the Phase-1 tunnel use the command show crypto isakmp sa and to
dump Phase-2 tunnel use show crypto ipsec sa commands as shown below:
VPN-test#show crypto ipsec sa
interface: Tunnel500
Crypto map tag: Tunnel500-head-0, local addr 10.10.120.39
protected vrf: (none)

current_peer 10.10.104.81 port 500
PERMIT, flags={origin_is_acl,}
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

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

spi: 0xDF685FC2(3748159426)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 21, flow_id: Onboard VPN:21, sibling_flags 80000046, crypto map: Tunnel500-head-0
sa timing: remaining key lifetime (k/sec): (4552507/14113)
IV size: 8 bytes
Status: ACTIVE

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

spi: 0xBDC1E53(198975059)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 22, flow_id: Onboard VPN:22, sibling_flags 80000046, crypto map: Tunnel500-head-0
sa timing: remaining key lifetime (k/sec): (4552507/14113)
IV size: 8 bytes
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel400
Crypto map tag: Tunnel400-head-0, local addr 10.10.120.39
protected vrf: (none)

current_peer 10.10.104.71 port 500
PERMIT, flags={origin_is_acl,}
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 13, #recv errors 0

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4
current outbound spi: 0x0(0)
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:
VPN-test#show crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.10.104.81 10.10.120.39 QM_IDLE 2012 ACTIVE
10.10.104.71 10.10.120.39 AG_INIT_EXCH 0 ACTIVE
10.10.104.71 10.10.120.39 MM_NO_STATE 0 ACTIVE (deleted)
VPN-test#show crypto isakmp
VPN-test#clear crypto isakmp
To see the track status use the command show track as shown below:
VPN-test#show track
Track 400
IP SLA 400 reachability
Reachability is Down
3 changes, last change 00:16:23
Latest operation return code: Timeout
Track 500

IP SLA 500 reachability

Reachability is Up
2 changes, last change 01:01:27
Latest operation return code: OK
Latest RTT (millisecs) 1
To dump the sla stats use the command show ip sla statistics as shown
below:
VPN-test#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

Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *02:29:07.511 UTC Sat May 19 2012
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 2
Operation time to live: Forever

Latest RTT: 1 milliseconds
Latest operation start time: *02:29:10.719 UTC Sat May 19 2012
Latest operation return code: OK
Number of successes: 2
Number of failures: 0
Operation time to live: Forever
To see the tunnel status use the command show crypto session as shown
below:
VPN-test#show crypto session
Crypto session current status
Interface: Tunnel400
Session status: UP-ACTIVE
Peer: 10.10.104.237 port 500
IKEv1 SA: local 10.10.120.41/500 remote 10.10.104.237/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
Session status: UP-NO-IKE
Peer: 10.10.104.71 port 500
Now simulate fail condition for the tunnel 400 and make sure after some time you see tunnel 500 becoming up and taking care of traffic:
VPN-test#show crypto session
Crypto session current status
Session status: UP-ACTIVE
Peer: 10.10.104.71 port 500
IKEv1 SA: local 10.10.120.41/500 remote 10.10.104.71/500 Active
Session status: DOWN-NEGOTIATING
Peer: 10.10.104.237 port 500
IKEv1 SA: local 10.10.120.41/500 remote 10.10.104.237/500 Inactive

To clear the Phase-1 sa use the command clear crypto isakmp as shown
below:
VPN-test#show crypto isakmp sa
dst src state conn-id status
10.10.104.81 10.10.120.39 QM_IDLE 2017 ACTIVE
10.10.104.71 10.10.120.39 QM_IDLE 2016 ACTIVE

VPN-test#clear crypto isakmp ?
<1-32766> connection id of SA
<cr>
VPN-test#clear crypto isakmp 2017

VPN-test#clear crypto isakmp 2016
To clear the Phase-2 sa use the command clear crypto sa

VPN Training & Configuration - Highighted

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VPN Training & Configuration - Highighted

Uploaded by

Copyright:

Available Formats

Zscaler

Technical Support Engineers

Copyright 2014 Zscaler, Inc. All rights reserved.

Content Development: Zscaler Training Development Team

Released: January 2014 v1.00

Copyright 2012 Zscaler, Inc. All rights reserved.

Chapter 1: VPN Configuration

Copyright 2014 Zscaler, Inc. All rights reserved. Page | 1

For Internal Use Only

1.1 > Introduction

Figure 1: IPsec VPN

1.2 > IPSec Goals

Page | 2 Copyright 2012 Zscaler, Inc. All rights reserved.

For Internal Use Only

1.2.1 Ensuring Confidentiality

1.2.2 Verifying Packet Integrity

1.2.3 Authenticating Peers

1.3 > IPsec Protocols

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 3

For Internal Use Only

Figure 2: ESP Modes

For Internal Use Only

1.4 > Phase 1

1.4.1 Main Mode

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 5

For Internal Use Only

Figure 3: IKE Phase 1 Main Mode

Page | 6 Copyright 2012 Zscaler, Inc. All rights reserved.

For Internal Use Only

1.4.2 Aggressive Mode

Figure 4: IKE Phase 1 Aggressive Mode

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 7

For Internal Use Only

1.5 > Phase 2

1.5.2 Dead Peer Detection

Page | 8 Copyright 2012 Zscaler, Inc. All rights reserved.

For Internal Use Only

Chapter 2: Configuring an IPsec

Figure 5: Configuring a VPN to the Zscaler Security Cloud

2.1 > Zscaler settings

2.1.2 Adding VPN Credentials

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 9

For Internal Use Only

Click Save and Activate Now.

2.1.3 Creating a New Location

2.1.4 Select Zscaler VPN concentrator

Page | 10 Copyright 2012 Zscaler, Inc. All rights reserved.

For Internal Use Only

2.2 > Customer network equipment config

2.3 > Working with Zscaler IPSec

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 11

For Internal Use Only

2.3.1 Only two SPI per customer IP address

2.3.2 IPSec Tunnel doesnt come up

2.3.2.2 Unassociated VPN Credential

Page | 12 Copyright 2012 Zscaler, Inc. All rights reserved.

For Internal Use Only

3.1 > Understand Zscaler components

Internet -> Racoon -> (over GRE) SMLB -> SME

3.1.2 Capturing network traffic

Copyright 2012 Zscaler, Inc. All rights reserved. Page | 13

For Internal Use Only

3.1.2.1 Capturing the encrypted traffic