Table of Content

Introduction

Configuration Steps for ZScaler IPSec Tunnal

1.       Dedicated ZScaler-Transport-VR and Tunnel Interfaces                                                   

2.       Org Resources and Traffic Identification       

3.       Zone and Security Policies

4.       IPSec Configuration

      a.        Policy Based Tunnel

      b.        Route Based Tunnel                                   

5.       Routing and Traffic Flow in Various Deployment Scenarios

      a.         ZScaler Tunnel only way out to Internet

      b.         ZScaler for Specific Applications and DIA (Local Breakout) for rest of the Internet

      c.         ZScaler for Specific Applications and HUB (SD-WAN) for rest of the Internet

      d.         ZScalser for specific destination subnets


Introduction

This considers deployment scenarios where customer want to establish an IPSec tunnel from a versa branch/hub to a remote branch, cloud services or datacenter where they don’t have Versa SD-WAN yet, or they are in process of phased deployment.


Below is an illustration to establish an IPSec tunnel with a remote 3rd Party device (we are considering ZScaler in this document).


Versa Branch may be deployed in different scenarios with similar setup, eg.

  • It has only way out to internet via one (or a redundant) ZScaler setup.
    • It has connectivity to ZScaler for specific applications, but for all other internet traffic it has Versa-Hub to send traffic to.
    • It has connectivity to ZScaler for specific applications and it has DIA-Breakout for rest of the internet traffic.

We will discuss these scenarios later in document. First list down key components required for this setup.

  • A dedicated Transport-VR to establish communication with ZScaler.
    • A Split-Tunnel interface which connects Lan-VR at one end and ZScaler-VR on other end.
    • An IPsec tunnel interface to terminate VPN endpoint in ZScaler-VR.
    • Static or dynamic (BGP) routing to exchange required routes between Lan-VR and ZScaler-VR.
    • IPsec configuration to establish tunnel between Versa and ZScaler nodes.
    • Security policies (if using NGWF) to allow specific flow to ZScaler.

         

      Configure Steps for ZScaler IPSec Tunnel 

 

1. Dedicated ZScaler-Transport-VR and Tunnel Interfaces


We recommend configuring a dedicated routing-instance when processing traffic to third party tunnels. Configuring separate VR  for IPsec gives better control over traffic in cases like, policy based VPN may not work with service/application PBR (using SD-WAN/PBF) in same routing instance or Route based VPN in transport may conflict with default route for WAN.


While configuring a dedicated VR, we will be adding following components to Flex CPE.

 

Add tunnel interfaces (Split and IPSec) in interfaces 

  


Define paired tunnel type for split-tunnel endpoints and create tvi-0/698 (Lan-VR) and tvi-0/699 (ZScaler-Transport-VR)

   


Define TVI interface IP address

 


Configure paired interface (tvi-0/699, part of ZScaler-VR) IP address (169.254.1.1/30).


 Add IPSec tunnel endpoint interface (tvi-0/301) and an IP (172.30.0.1/30)

 


If you plan to configure redundant IPSec to ZScaler, add an additional tunnel endpoint, as illustrated in image above (e.g. tvi-0/401) and follow similar steps as followed for tvi-0/301.


Add new VR (routing instance) ZScaler-Transport-VR and add interfaces tvi-0/699 and tvi-0/301(add tvi-0/401 if you plan to have redundant tunnel) to it.


Similarly, add interface tvi-0/698 to Lan-VR.


 

2. Org Resources, Traffic Identification 

We need to map newly added interfaces and VR to appropriate Org for traffic identification and resource management.

a. Add newly added tunnel interfaces (tvi-0/698, tvi-0/699, tvi-0/301) to traffic identification

Navigate to Others (tab) => Organization => Limits => (select Org) => Traffic Identification

    

b. Add ZScaler-Transport-VR to the resource of proper Org.

 Navigate to Others (tab) => Organization => Limits => (select Org) => Resources

 

 

3. Zone and Security Policy

 

Now create zones mapping for these interfaces and VR. Also, make sure that you have already completed steps in 2.a and 2.b (Traffic Identification and Resource mapping), else interfaces will not appear in Zones. This segment is optional if you are not using NGFW (Next-Generation Firewall) feature with this Versa Appliance. 

Segment 5.b is explicitly applicable for appliances with NGWF features.


a. Add Zones Entries


Add tvi-0/698 as zone L-ST-LAN-VR-ZScaler (Lan end Split-Tunnel between LAN-VR and ZScaler)

Add tvi-0/699 as zone Z-ST-LAN-VR-ZScaler (ZScaler end Split-Tunnel between LAN-VR and ZScaler)


Add tvi-0/301 as zone Intf-ZScaler-Zone (Interface part of ZScaler-VR)

 

b. Add appropriate security policies permitting flow from Lan to ZScaler tunnel.

(This part is applicable only to CPEs with the Next Gen Firewall feature.)

 

Add source-destination zones to allow traffic in below two routing-instances


For LAN-VR: from Lan interface (Intf-Lan) to Lan-side-Split-Tunnel interface (L-ST-LAN-VR-ZScaler)For ZScaler-VR: From ZScaler-side-Split-Tunnel Interfaces (Z-ST-LAN-VR-ZScaler) to ZScaler-Tunnel interface (Intf-ZScaler).

Optionally, Lan-Subnet can be supplied in source-address.

 

If tunnel is used for specific applications, protocol/ports/applications and other details can be optionally supplied. Finally, enforce action Allow.

 

Ensure that no other existing rule above this new rule is affecting the flow.


4. IPSec Configuration


Parameters defined in IPSec are should be identical on both devices of tunnel endpoints. Furthermore, IPSec tunnel can be configured to as policy-based(Traffic-selectors) or route-based. 

In you are configuring redundant tunnels to Zscaler then configure Route-Based IPSec will give the option to play with Route preferences and prefer one path over others.

A. Policy-Based IPSec Tunnel

In a policy Based tunnel, a policy defines the traffic that is sent to tunnel and used as Traffic-Selector in Phase-2 negotiation (Its important to have matching Traffic-selector on both sides, as its part of IPSec proposal negotiation).


Add a new IPSec VPN Profile. As suggested in the image below. Configure tunnel type as Policy-Based and define source and destination prefix. Specify protocol/ports if required, else leave them default,


Routing Instance should be the instance where wan interface (Local Tunnel Endpoint interface/IP address) is configured under, we can define local interface or local ip we have on wan interface  as local tunnel endpoint. Here it is Internet-Transport-VR and Internet link IP address


Tunnel Routing Instance is where the user traffic will be encrypted and decrypted (based on traffic-selector) and pushed into tunnel. Zscaler-Transport-VR in our case.


Peer IP  Remote endpoint IP address.

 

 Define IKE parameters as mutually agreed to configure with remote peers. In the sample configuration, authentication type PSK and Identity as IP Address.

 FQDN or email could also be configured as local and/or peer identity.

 

 Define IPSec parameters also as mutually decided to configure at ZScaler and Versa.

 

B. Route-Based IPSec Tunnel

Route Based Tunnel is helpful when you want your routing control (or wish to run routing protocol over IPsec) to decide tunnel traffic. TVI acts as exit interface for tunnel traffic. In route-based IPsec traffic-selector are default(0.0.0.0/0)


Tunnel configuration select Route-Based and Interface (tvi-0/301, which we defined in Section.1).


 

IKE and IPSec configuration will remain similar (as explained in policy-based ipsec) and mutually identical to ZScaler configuration.

  

5. Routing and Traffic Flow in Various Deployment Scenarios

Flow of User and VPN traffic

LAN-VR <-(User traffic over Split-Tunnel)-> ZScaler-Transport-VR <- (IPsec Traffic over Internet-VR) -> Zscaler IPsec Peer


We need to ensure that forwarding and return routes are present in each respective VRs. Either we can have  BGP peering for dynamic routes exchange over the split tunnel or simple static route will also help in most of the cases. 


A minimum of routing requirement will be as following,

  1. In Lan-VR: Add a default route with a next-hop 169.254.1.1(Zscaler-Transport-VR split-tunnel TVI IP address)
    1. In ZScaler-Transport-VR: Add a route for lan-Subnet with a next-hop 169.254.1.2 (LAN-VR split-tunnel TVI IP address)
    2. If you are using a route-based IPSec tunnel, add a default route in ZScaler-Transport-VR with next-hop as peer tunnel endpoint IP (172.30.0.2, as in our illustration).
    3. If you are configuring redundant ZScaler Instances with dual IPSec tunnels, you can use BGP routing or simple static routes with the help of route preferences.
    4. As local tunnel endpoint is already in Internet-Transport-VR we don't need additional routing for peer tunnel endpoint


Deployment Scenarios


In application based Local/Internet break out have will be using Policy Based Routing.(PBF/ SD-WAN policy with Next-hop)


Policy Based Routing Concepts: 

  • PBF policy: is used for evaluation when traffic matches a non-sdwan in routing instance. Route can be static/connect/ospf/ebgp/RTI, PBF with nexthop can be used when local DIA is enabled on the branch and the default route on the LAN-VR is pointing to Transport-VR.
  • SD-WAN policy: is used for evaluation when traffic match a sdwan learned route(l3vpn). SDWAN policy with nexthop can be used in case of Remote DIA, where default route is learned from SD-WAN and preferred.
  • App Based PBR:  Its also important to understand that in app-based PBR, initial sessions will take next hop based on routing table(not PBF/SDWAN Nexthop) and session should succeed to help build the app cache first, it can take few session to fully populate the app-cache as some application can resolve to different IP in an region. Once new session starts matching the app-cache table, then it will be forward based on next-hop configured in PBF/SDWAN policy. So its important that initial session succeed based on default routing. 


A. ZScaler for all internet traffic out


In this case, versa appliance will keep forwarding all SD-Wan traffic via overlay. LAN-VR will learn specific routes for SD-WAN environment 


  1. For traffic destined to internet, LAN-VR will forward traffic to ZScaler-Transport-VR, which will route it via IPSec tunnel to ZScaler device.
    1. Lan-VR will have a default route to ZScaler-VR (NH: 169.254.1.1).
    2. ZScaler-VR will have a default route towards IPSec Tunnel (NH: 172.30.0.2).
    3. ZScaler-VR will also have a reverse static route to LAN-VR (NH: 169.254.1.2)
    4. This routing can be achieved using BGP or Static routing.


B. ZScaler for Specific Application Traffic (eg, 365/Business Apps) rest of the internet traffic through DIA (Local Breakout)


In this case, LAN-VR will have a default route towards Internet-Transport-VR only. Specific application traffic needs to be routed towards ZScaler-VR. Here, we will use policy-based routing (PBF with next hop action) to achieve this flow.

Configure a PBR Rule. Select source zone as Intf-Lan-Zone (optionally configure Lan Subnet under Source Address)



Select desired application (to send to ZScaler) under application option



Enforce action Allow Flow and either set next-hop 169.254.1.1 (next-hop to enter ZScaler-VR).

   

Make sure that you don’t have a default route in LAN-VR towards ZScaler-VR, else normal Internet going traffic through local DIA will also be routed to ZScaler-Transport-VR. If you have a default route to both, make sure its preference is higher than the default route learned from Internet-Transport-VR

However, a route for LAN-Subnet is a must in ZScaler-VR for the return packet flow.

 

C. ZScaler Specific Application (eg, 365/Business Apps), rest of the internet traffic through the hub (SD-WAN)


In this case, LAN-VR has an active default route towards a hub (over sdwan). Specific application traffic needs to be routed towards ZScaler-VR. Here, we will use policy-based routing (SD-WAN policy with next-hop action) to achieve this flow.


Configure a SD-Wan policy for specific applications that needs to be forwarded to ZScaler over IPSec in ZSclaer-Transport-VR. 


Add SD-WAN policy rule for internet traffic. Match Source Interface Intf-Lan-Zone and (optionally) add Lan-Subnet.


Select desired application (to send to ZScaler) under application option


Enforce action Allow Flow and set next-hop 169.254.1.1 (next-hop to enter ZScaler-VR).


In this setup also, ensure that Lan-VR doesn’t have default route towards ZScaler-VR (via L-ST-Lan-VR-ZScaler interface), as explained in deployment case-1. Else, normal Internet going traffic through SD-WAN (Hub) will also be routed to ZScaler-Transport-VR. If it has to be there, make sure its preference is higher than the default route learned from SD-WAN.

A route for Lan-Subnet is must in ZScaler-VR for return packet flow. This can be defined statically.

 

 

D. ZScaler for Specific Destination Subnets (eg, 99.9.9.0/24), rest all traffic flow through local DIA breakout or via Hub location.

This deployment is easier and requires no PBR or SD-WAN configuration for this flow. Just add a static route for 99.9.9.0/24 in Lan-VR towards ZScaler-VR.

ZScaler-VR will also have a route of Lan-VR through Split-tunnel. If destination subnets are dynamic, use of BGP is recommended.