Transcription
Zscaler Internet Access (ZIA) andCisco SD-WAN Deployment GuideFebruary 2020Version 3.1
Table of Contents1 Document Overview . 61.11.21.31.41.51.61.7Document Audience . 6Hardware Used . 6Software Revisions . 6Request for Comments . 6Document Prerequisites . 7Document Revision Control . 8Cisco Design Overview . 91.7.11.7.21.7.31.7.41.7.51.8GRE and IPsec Tunnels. 10Tunnel Liveliness . 10Transport-side vs Service-side Tunnels . 12Traffic Redirection . 12Cisco SD-WAN Configuration Requirements . 14Lab Topology and Configuration Overview . 182 Configuring Zscaler Internet Access (ZIA). 212.12.22.3Overview . 21Logging into ZIA . 23Configuring ZIA for GRE Tunnel . g ZIA for Ipsec Tunnel . Provision GRE Tunnel. 24Navigate to Locations. 24Add a Location . 25Enter Location Data . 26Verify Location Information and Save . 27Confirm Changes Have Been Submitted . 28Activate Changes . 29Navigate to VPN Credentials . 30Add a VPN Credential . 31Enter VPN Credential Data . 32Verify VPN Credential . 33Navigate to Locations. 34Add a Location . 35Enter Location Data . 36Add VPN Credential to Location and Save . 37Confirm Changes Have Been Saved . 38Activate Pending Changes . 392.5.12.5.2Activate Changes . 39Activation Confirmation . 403 Configuring Cisco SD-WAN. 413.13.2Log into Cisco SD-WAN vManage . 41Configure GRE Tunnel (transport-side tunnel) . 42Page 2 of 162
03.2.113.2.123.2.133.3Configuring Ipsec Tunnel (Transport-side and Service-side) . .103.3.113.3.123.3.133.3.143.4Feature and Device Template Modifications . 42Add Feature Template for the Primary GRE Tunnel . 45Select VPN Interface GRE Feature Template. 46Set GRE Basic Configuration and Source Interface . 46Set GRE Interface Destination . 47Enable GRE Keepalives. 49Create Feature Template for the Secondary GRE Tunnel . 50Add GRE Interface Feature Template to Device Template. 52VPN 0 Template . 53Configuration Update . 54Add GRE Route . 56Configuration Update . 57Verify Tunnel Operation . 59Feature and Device Template Modifications . 61Add Feature Template for the Primary Ipsec Tunnel . 64Select VPN Interface Ipsec Feature Template . 66Set Ipsec Basic Configuration and Source and Destination Interface . 66Configure IKE Parameters . 68Configure Ipsec Cipher-suite. 69Create Feature Template for the Secondary Ipsec Tunnel . 70Add Ipsec Interface Feature Template to Device Template . 72VPN 0 or VPN 1 Template . 73Configuration Update . 74Add Service Routes . 76Configuration Update . 80IOS XE SD-WAN Ipsec Tunnel Workarounds . 82Verify Tunnel Operation . 85Configuring Layer 7 Health Checks . 863.4.13.4.23.4.33.4.4Feature and Device Template Modifications . 87Add System Template with Tracker . 88Add IPSEC Tunnel Interface with a Tracker . 89Add New Feature Templates to the Device Templates. 904 Verifying Service Configuration . 914.1Request Verification Page . 915 Requesting Zscaler Support. 925.1Gather Support Information . 925.1.15.1.25.1.35.1.45.1.5Obtain Company ID. 92Save Company ID . 93Enter Support Section . 94Create and Submit Support Request (GRE Provisioning) . 95Reviewing Provisioning Email . 966 Appendix A: Zscaler Resources . 977 Appendix B: Cisco SD-WAN Resources . 987.1Cisco SD-WAN References . 98Page 3 of 162
7.27.37.47.5Base Feature Templates and Configuration Values Used . 98Onboarding the WAN Edge Devices . 102Upgrade Software on WAN Edge router . 105Create a Device Template . 5.107.5.117.5.127.5.137.6vEdge CLI Configuration . 1507.6.17.6.27.6.37.6.47.7Log into vManage. 108Create VPN 0 Feature Template. 108Create the VPN 0 Internet Interface Templates . 116Create the VPN 0 MPLS Interface Templates . 122Create VPN 1 Feature Template. 126Create the VPN 1 Interface Template . 128Create the VPN 512 Interface Template . 131Create the AAA Template . 133Create Device Template (vEdge Router) . 135Create Device Template (IOS XE SD-WAN Router) . 139Attach Device to Device Template (vEdge Router) . 141Attach Device to Device Template (IOS XE SD-WAN Router) . 146Verify Control Connections . 148Configure Base Connectivity . 150Add GRE Tunnels with a GRE route . 152Add Ipsec Tunnels with an Ipsec route . 153Add Layer 7 Health Check . 155IOS XE SD-WAN CLI Configuration . 1567.7.17.7.2Add Service-side Ipsec Tunnels with an Ipsec route . 158Add IOS XE SD-WAN Workarounds . 159Page 4 of 162
Terms and AcronymsAcronymDefinitionDPDDead Peer Detection (RFC 3706)GREGeneric Routing Encapsulation (RFC2890)IKEInternet Key Exchange (RFC2409)IpsecInternet Protocol Security (RFC2411)OAMOperation, Administration, and ManagementOMPOverlay Management Protocol (Cisco SD-WAN)PFSPerfect Forward SecrecySSLSecure Socket Layer (RFC6101)TLSTransport Layer Security (RFC5246)vBondSD-WAN EdgevSmartXFFZAPPCisco SD-WAN orchestrator facilitates the initial bring-upauthentication and authorization of the network elements.Cisco SD-WAN Router PlatformCisco SD-WAN centralized control plane and policy engineX-Forwarded-For (RFC7239)Zscaler End-point Client ApplicationZIAZscaler Internet Access (Zscaler)ZPAZscaler Private Access (Zscaler)Page 5 of 162
1 Document OverviewThis Deployment Guide document provides configuration guidance for integrating ZscalerInternet Access (ZIA) and Cisco SD-WAN successfully. There are examples to show how toprovision a new service with ZIA and Cisco SD-WAN using GRE or Ipsec tunnels. For CiscoSD-WAN, configurations that use feature templates through vManage and CLI are both shown.All examples in this guide presumes the reader has a basic comprehension of IP Networking.The Cisco SD-WAN portion of this document was authored by Cisco1.1 Document AudienceThis document was designed for Network Engineers and Network Architects. For additionalproduct and company resources, please refer to the Appendix section.1.2 Hardware UsedBoth Cisco vEdge and IOS XE-SD-WAN routers were tested. For the vEdge router, both avEdge 100b and ISR1100-4G were tested and for the IOS XE SD-WAN router, an ISR4331was tested.1.3 Software RevisionsThis document was written using Zscaler Internet Access version 6.0 and Cisco SD-WANversion 19.2.099 vEdge and 16.12.1e IOS XE SD-WAN code. In addition, Cisco SD-WAN19.3.0 vEdge and 16.12.1r IOS XE SD-WAN code were tested as well.1.4 Request for CommentsWe value the opinions and experiences of our readers. To offer feedback or corrections for thisguide, please contact partner-doc-support@zscaler.com.Page 6 of 162
1.5 Document PrerequisitesZscaler Internet Access (ZIA)§§A working instance of ZIA 6.0 (or newer)Administrator login credentials to ZIACisco SD-WAN This document assumes you have the Cisco SD-WAN controllers already built andoperational, either through the Cisco cloud service or on-premise. You can usevManage to configure and manage the WAN Edge routers (recommended) or you canuse CLI.It is also assumed that the WAN Edge devices are already connected to the controllersin the SD-WAN overlay, and a basic device template configuration from vManage hasbeen deployed on them. See Appendix 7 for onboarding information, deploying basedevice template instructions, and CLI-equivalent configurations.Using vManage (GUI)§A working instance of Cisco SD-WAN vManage with administrator login credentials.Using CLI:§§Must have SSH or console access to the device.Must have the valid user credentials for the Cisco WAN Edge router.Page 7 of 162
1.6 Document Revision ControlRevisionDateChange Log1.01.11.2August 2017August 2017September 20171.3September 20182.0March 20193.0January 20203.1February 2020Initial document by Zscaler and ViptelaUpdated Viptela references to Cisco SD-WANMinor editsMajor update:§ Updated ZIA screen captures to ZIA 5.6§ Added Ipsec Section§ Other supporting editsAdded GRE and Ipsec template creationUpdated for 19.2.099 and 19.3.0 code, added IOS XESD-WAN router information, added design information,added L7 health checking, tested ISR1100-4GIncorporated review feedbackPage 8 of 162
1.7 Cisco Design OverviewEnterprises can take advantage of secure local Internet breakout by using Cisco SD-WANcombined with Zscaler. Using Cisco SD-WAN, the network administrator can decide whattraffic should be forwarded to Zscaler, using either GRE or IPsec tunnels (with NULLencryption).The following example topology shows a Cisco SD-WAN network with two transports (MPLSand Internet) and the SD-WAN controllers reachable through the Internet cloud. Two branchsites are shown with a datacenter site. IPsec tunnels are built between each WAN Edge routerat each site for corporate traffic. GRE or IPsec primary and secondary tunnels are built toZscaler for direct Internet traffic.Figure 1: Example SD-WAN and Zscaler NetworkPage 9 of 162
1.7.1 GRE and IPsec TunnelsZscaler supports GRE and IPsec tunnels. For GRE, traffic is encapsulated in an IP packetusing IP protocol type 47. Using GRE with Zscaler requires a static IP address.IPsec, using IKE, does not require a static IP address, and instead relies on a FQDN for IKE IDversus an IP address. Unlike typical site-to-site deployments of IPsec which encrypt traffic,when using IPsec to Zscaler for Internet-destined traffic, NULL encryption is to be used. IKEuses UDP port 500, or in the case of NAT traversal, UDP 4500. Traffic is encapsulated in anESP packet using IPv4 protocol 50 (and is non-encrypted in this case).A GRE or IPSec tunnel is defined by a source IP address/interface and a destination IPaddress pair. Multiple tunnels can exist that reference the same source IP address, but eachmust have a unique destination IP address.1.7.2 Tunnel Liveliness1.7.2.1 KeepalivesGRE Tunnel Keepalives for GRE tunnels and Dead Peer Detection (DPD) for IPsec tunnelsare ways for the local router to determine whether the remote end of the tunnel is reachable.In the case of GRE tunnels, a keepalive packet is sent and looped back to the sender from theremote end. The default timers are one keepalive sent every 10 seconds, and after 3 retries,the tunnel is declared down.Note: If the router sits behind a NAT device, GRE tunnel keepalives are not passed, sokeepalives must be disabled in this case. Keepalives are disabled by specifying 0 for thekeepalive interval and 0 for the retry value.In the case of IPsec tunnels, Dead Peer Detection is used, which can be either periodic or ondemand. Periodic works similarly to keepalives, where a packet is sent at every interval andthe remote end sends an acknowledgement. The default timers are one DPD packet sentevery 10 seconds, and after 3 retries, the tunnel is declared down. In the case of on-demand,packets are only sent when traffic is being sent but no traffic is being received.Note: IKEv2 DPD timing changed for vEdge routers starting in 18.4.303 code. Instead of DPDbeing sent at every constant interval, the interval gets longer for each retransmitted DPDpacket. The interval is calculated for retransmission attempt N using the formula [interval*1.8 (N-1)], so for an interval of 10 with a retry value of 3, the retransmission attempt is 10 secondsfor the first retry packet, 18 seconds for the next retry packet, and 32.4 seconds for the thirdretry packet.Page 10 of 162
Note: vEdge routers currently support only periodic DPD. On-demand DPD is currently thedefault for IOS XE SD-WAN routers.Note: Zscaler requests that GRE Keepalives and DPD packets are sent no more than oneevery 10 seconds.1.7.2.2 Layer 7 Health ChecksGRE Keepalives and Dead Peer Detection can validate whether the network path is upbetween the tunnel source and destination, but they cannot verify whether a particular serviceor application is up and operational through the tunnel and ZEN node.Layer 7 health checking allows you to monitor performance based on an HTTP request andresponse and allows you to failover to an alternate tunnel based on the results.A tracker is defined globally which defines an HTTP URL. The endpoint in the URL mustrespond to an HTTP request and return a 200 OK response in order for the tracker to be in anUP state. The tracker is attached to a tunnel, where the software periodically sends HTTPrequests over that tunnel. The HTTP requests are directed to the destination tunnel interfaceIP address, which is used as an HTTP proxy for the requests. DNS for the URL in the requestis performed by the HTTP proxy endpoint. By default, requests are sent every 60 seconds butcan be set to a minimum interval of 10 seconds. If there is no response, three requests areresent before the tunnel is declared down and the route is withdrawn to the tunnel. The trackercomponents also measure latency and compare it with the SLA threshold defined under thetracker configuration. If latency exceeds the configured SLA, the tunnel interface is alsomarked as down and the routes withdrawn to the tunnel.Note: To health-check the application stack of the Zscaler node, Zscaler recommends notperforming L7 health checks to commonly visited websites, but instead recommends using thefollowing URL for the tracker, which is not publicly accessible, but only reachable through aZscaler tunnel:http://gateway. zscaler cloud .net/vpntestNote: Only vEdge routers support L7 health checks at this time, beginning in version 19.3.0.L7 health checking is also supported for transport-side tunnels only, not for service-sidetunnels.Page 11 of 162
1.7.3 Transport-side vs Service-side TunnelsTunnels can be built either as transport-side or service-side tunnels. With transport-sidetunnels, the tunnel resides entirely in VPN 0, and with service-side tunnels, the tunneldestination and/or source definitions are reachable from VPN 0, but the tunnel interface itself isconfigured in the service VPN.Service-side tunnels allow you to define a different tunnel per VPN and allow you to keep yourVPN traffic, such as guest and corporate traffic, separated into different tunnels. For transportside tunnels, all VPN traffic can use the same tunnel, simplifying the configuration.Note: For IOS XE SD-WAN routers, only service-side IPsec tunnels are supported at this time.1.7.4 Traffic RedirectionOnce the GRE or IPSec tunnel is built, there are two ways to redirect traffic to the tunnel:§§With a static route to rely on destination-based routing, which is typically a defaultroute where all internet-bound traffic is sent.With a centralized data policy which allows you to customize the traffic sent tothe Zscaler service.1.7.4.1 Static RouteTransport-side Tunnels (applies to vEdge only at this time)For transport-side tunnels, the source and destination and the GRE or IPsec tunnel interfaceitself resides in the transport VPN (VPN 0). To direct traffic from a service VPN, a route shouldbe installed in the service VPN which points to the GRE or IPsec interface in VPN 0 as thenext hop. In the vManage GUI, this route is described as a GRE Route or IPsec Route in theVPN feature template.ip gre-route 0.0.0.0/0 vpn 0 interface gre1 gre2ip ipsec-route 0.0.0.0/0 vpn 0 interface ipsec1 ipsec2With these static routes, the GRE or IPsec tunnels are implemented as active/standby only.Only when the first interface is removed from the route table through GRE keepalive, DPD, orL7 health-check failures will the second interface become active.Note: When using static routes specifying the interface as the next hop, GRE tunnel interfacescan be IP unnumbered, but IPsec tunnels do not come up and active unless an IP address isassigned to the tunnel interface.Page 12 of 162
Service-side TunnelsThere are multiple ways to set up service-side tunnels. One way is for the source anddestination of the tunnel to reside in the transport VPN (VPN 0). The tunnel interface itselfresides in the service VPN. To direct traffic from a service VPN, a route is installed in theservice VPN and the next-hop IP address becomes the remote end of the tunnel. The next-hopaddress is already reachable from the service VPN, so nothing more needs to be configured.vpn 1interface ipsec1ip address 11.1.1.1/30interface ipsec2ip address 11.1.2.1/30ip route 0.0.0.0/0 11.1.1.2ip route 0.0.0.0/0 11.1.2.2In this configuration, the tunnels are active/active and traffic can load share between thembased on a hash of the flow. You can tag one route with a higher admin distance so that itbecomes a backup route instead of using equal cost paths to diverse Zscaler nodes. In thiscase, interface tunnels are required to be assigned an IP address in order to configure theservice VPN IPv4 route needed.Note: In vManage when defining a route in the service VPN, you cannot specify an interface(gre1, ipsec1) for a next-hop when the tunnel itself resides in the service VPN because thisroute next-hop is only valid when the tunnel itself resides in the transport VPN (VPN 0).Note: Service-side tunnels, where the tunnel interface itself resides in the service VPN, but thesource and destination of the tunnel resides in the transport VPN is supported only for IPsectunnels for both vEdge and IOS XE SD-WAN routers.Note: In IOS XE SD-WAN, commands get translated from vManage into IOS XE-compatiblecommands. In IOS XE SD-WAN, VPN 0 is the global table, the vrf keyword is used instead ofvpn, and gre and ipsec tunnel interfaces get translated into a Tunnel10000x format when theconfiguration is pushed to the router.Page 13 of 162
1.7.4.2 PolicyTraffic can be directed to Zscaler using a centralized policy instead of using static routes. Inorder to direct data traffic to a tunnel using a centralized data policy, you first advertise theservice in the service VPN, and you then create a centralized data policy on the vSmartcontroller to forward matching traffic to that service. This utilizes service chaining to advertise aservice so that other WAN Edge routers can utilize the service even if they are not local. Seefor additional msinterfaces-book/configure-interfaces.html#id 113930Note: The IOS XE SD-WAN router currently does not support service chaining. As aworkaround, a data policy using matches and setting the next hop as the remote end of thetunnel can be configured instead.1.7.5 Cisco SD-WAN Configuration RequirementsGRETo set up a GRE tunnel, you need to minimally configure a source for the tunnel, which can bean IP address or source interface of the SD-WAN router, as well as a tunnel destination, whichis the Zscaler node. For a transport-side tunnel, the source of the tunnel is typically the portconnected to the Internet transport in VPN 0, which is reachable to the Zscaler node. Thisaddress needs to be a publicly-routable IP address or the SD-WAN router needs to sit behinda NAT device that can NAT the source IP address in order to get a response back from theZscaler node. Note that because the Zscaler GRE tunnel configuration is a manualprovisioning process at this time, this source IP address must be a static IP address andcannot be changed. DHCP can only be used if the router is guaranteed to receive the static IPaddress that’s been provisioned in Zscaler – a random IP address cannot be obtaineddynamically through DHCP. Once the tunnel is up, user traffic sent over it to Zscaler does notneed to be subjected to NAT and can be sent sourced as private (RFC 1918) addresses.The IPv4 address for the tunnel is optional for transport-side tunnels since you are using aninterface as the next-hop in the route.In the vManage GUI, you specify the name of the tunnel, which is gre[1.255], and this namecan be referenced in the GRE route if needed.Page 14 of 162
GRE Keepalives are turned on by default with an interval value of 10 seconds and 3 retries.Note that if the router sits behind a NAT device, keepalives must be disabled, as they do notpass through the NAT device. To disable keepalives, set the Interval and Retries value to 0.To prevent fragmentation, set the IP MTU to 1476 bytes and the TCP MSS to 1436 bytes toaccount for the GRE packet overhead (24 bytes).Note: GRE is supported only by the vEdge router at this time.IPsecTo set up an IPsec tunnel, you need to configure a source for the tunnel, which can be an IPaddress or source interface of the SD-WAN router, as well as a tunnel destination, which is theZscaler node. The tunnel destination can be an IP address or FQDN for a vEdge router andonly an IP address at this time for the IOS XE SD-WAN router. For a transport-side tunnel, thesource of the tunnel is typically the port connected to the Internet transport in VPN 0, which isreachable to the Zscaler node. This address needs to be a
Using GRE with Zscaler requires a static IP address. IPsec, using IKE, does not require a static IP address, and instead relies on a FQDN for IKE ID versus an IP address. Unlike typical site-to-site deployments of IPsec which encrypt traffic, when using IPsec to Zscaler for Internet-destined traffic, NULL encryption is to be used. IKE
