[VIDEO] Forwarding Policy

Once a Cloud Connector is up and operational, traffic will be directed to it via cloud routing. This is generally done through a simple default route. Regardless, after traffic has reached the Cloud Connector, there are three Forwarding policy types available to direct traffic out of the cloud: Traffic Forwarding, Log and Control, and DNS Policies.

  • Log and Control Policies allow an administrator to identify control-plane traffic from specific cloud locations and redirect this traffic to a specified Zscaler Logging Gateway. Generally speaking, Zscaler recommends that this option be adjusted only under the supervision of Zscaler support, however, since the appliance will automatically select a Log and Control Gateway that compliments the Data Plane PoP chosen.
  • DNS Policies find their usefulness with regards to ZPA use-cases. As discussed in other videos, the Cloud Connector must see DNS traffic from workload machines in order to proxy their traffic within ZPA. The traffic is proxied via synthetic IP addressing hosted within the Cloud Connector. Administrators can use DNS Policies to allow, block, and forward DNS requests for ZPA-bound traffic. Furthermore, when forwarding to ZPA, DNS Policies also allow the administrator to specify the synthetic IP ranges used.
  • Traffic Forwarding Policies are by far the most common policy adjustment that a customer may wish to entertain. These policies allow administrators to influence how data plane traffic is directed through the Cloud Connector.

In this video, we’ll explore:
[0:00 to 3:25] Overview of Forwarding Policies and policy types
[3:25 to 7:01] Configuring Traffic Forwarding rules
[7:01 to 7:55] Key Takeaways

Transcript

Hello, my name is Aaron and I’m one of the Principal Technical Product Specialists for Zscaler Cloud Workload Protection.

In this video, we’ll discuss how Forwarding Policy can be used to influence how the Cloud Connector treats incoming workload traffic.

Once a Cloud Connector is up and operational, traffic will be directed to it via cloud routing. This is generally done through a simple default route. Regardless, after traffic has reached the Cloud Connector, there are three Forwarding policy types available to direct traffic out of the cloud: Traffic Forwarding, Log and Control, and DNS Policies.

Log and Control Policies allow an administrator to identify control-plane traffic from specific cloud locations and redirect this traffic to a specified Zscaler Logging Gateway. Generally speaking, Zscaler recommends that this option be adjusted only under the supervision of Zscaler support, however, since the appliance will automatically select a Log and Control Gateway that compliments the Data Plane PoP chosen.

DNS Policies find their usefulness with regards to ZPA use-cases. As discussed in DNS Setup for AWS and Azure videos, the Cloud Connector must see DNS traffic from workload machines in order to proxy their traffic within ZPA. The traffic is proxied via synthetic IP addressing hosted within the Cloud Connector. Administrators can use DNS Policies to allow, block, and forward DNS requests for ZPA-bound traffic. Furthermore, when forwarding to ZPA, DNS Policies also allow the administrator to specify the synthetic IP ranges used.

Traffic Forwarding Policies are by far the most common policy adjustment that a customer may wish to entertain. These policies allow administrators to influence how data plane traffic is directed through the Cloud Connector. There are three options available within the Traffic Forwarding Policies workflow:

  • The Direct forwarding option allows traffic matching the criteria defined to bypass ZIA/ZPA and hair-pin back out of the appliance, where it will follow underlay cloud Route Tables towards the destination. This type of forwarding rule is useful for allowing workloads to reach cloud-native services without having to “boomerang” through ZIA or ZPA. For instance, when accessing an AWS S3 Bucket, a Direct Forwarding Rule can be created to allow AWS workloads to access the resource directly, without being inspected by ZIA. Furthermore, Direct Forwarding Rules also find usefulness in IP whitelisting, since traffic can be forwarded straight from the cloud, where a predictable IP will be used (in this case, the NAT Gateway). Keep in mind, however, that this traffic will be Source NAT’d to the Service Interface IP Address first, then NAT’d again when egressing the cloud.

  • Second, the Zscaler Internet Access (ZIA) option, as implied, will allow traffic matching the criteria defined to be forwarded to the Zscaler Internet Access cloud for inspection. By default, for ZIA customers a rule will be automatically created for you to send all traffic to ZIA. This may be acceptable, or, a customer may wish to modify this behavior by creating more specific rules to define which traffic should be delivered to ZIA for inspection.

  • And finally, using the Zscaler Private Access (ZPA) option, traffic matching the criteria defined will be forwarded to the Zscaler Private Access cloud. The Cloud Connector automatically downloads ZPA Application Segments from your ZPA portal. Hence, any traffic it receives that is destined to these segments will be proxied, assuming it is permitted within the ZPA Access Policy and Client Forwarding Policy. Similar to ZIA, for ZPA customers, a default rule will be added automatically to ensure ZPA-bound traffic is automatically forwarded to the ZPA Broker.

Whether using DNS Policies, Log and Control, or Traffic Forwarding, each of the three options permits the administrator to define a range of match criteria. This demonstration will focus on DNS Policies and Traffic Forwarding Policies, but the workflow remains roughly the same regardless of the policy chosen.

The forwarding policy is located in the Policy Management section of the Cloud Connector portal, under the Forwarding menu. Rule creation and assessment models ZIA and ZPA workflows. More specific rules should be ordered near the top, while more broad rules ordered towards the bottom. For our first example, let’s assume that we’d like to send traffic destined for Office365 directly out of Azure, instead of inspecting with ZIA. Since this is data plane traffic, we’ll use the Traffic Forwarding Policy type with a Direct Forwarding Rule to accomplish this.

Click the Add Traffic Forwarding Rule button

Set the Rule Order appropriately, so as not to conflict with other rules, provide a name and set the Forwarding Method to Direct. In the Criteria section, notice the options available to define how traffic that should adhere to this rule is matched. Within the General tab, Locations identify the various VPCs or VNets from which your workloads send traffic. As Cloud Connector appliances are brought online, the VPC or VNet they are installed within will automatically populate this menu. Location Groups can be created to organize various cloud VPCs and VNets - such as a “Dev VPCs” Location Group, “Prod VPCs” Location Group, etc. If there are many locations and associated sub-locations within your organization, consider using Location Groups. Branch and Cloud Connector Groups allow you to match traffic transiting specific Cloud Connector appliances.

In the Services menu, you can choose the protocol type that defines the traffic via the Network Service menu. For traffic profiles with multiple protocol types, Network Service Groups can be created to group the traffic for easier policy creation.

Within the Source tab, source IP Addresses or groups of IP Addresses can be used to define the source of incoming traffic that should adhere to this rule. IP addresses can be written as an individual host, in CIDR notation, or as a range of IP addresses using a hyphen.

In the Destination tab, you can enter the IP addresses and/or fully qualified domain names (FQDNs) that this traffic is destined for. Similarly, you can group together Destination IP Addresses and FQDNs that you want to control in a Forwarding Policy rule by Destination IP/FQDN Groups. And finally, as the name suggests, Destination Country allows this match criteria to specify the destination country of the remote machine.

Please note that wildcard domain identifiers (“*”) are not currently supported and that Destination criteria is not supported when Zscaler Private Access is selected as the Forwarding Method.

For our example here, we’ll select our Azure Cloud Connector, then set a Destination FQDN of sharepoint.com and sharepointonline.com. Once we activate our change, we can be assured that Sharepoint traffic to these FQDNs will now egress Azure locally, instead of being inspected by ZIA.

Similarly, similar match criteria can be set up to direct traffic to ZIA and ZPA as well. Remember, ZIA and ZPA have default policies out of the box that will forward traffic to their respective service.

As mentioned previously, the Cloud Connector proxies traffic for ZPA using synthetic IP addressing. This pool, by default, is 10.254.0.0/19, as shown on your screen within the IP & FQDN Group menu. Let’s assume that we want to update this pool to use the 10.253.0.0/16 address space for our AWS clouds, so as not to overlap with existing workload subnets in those regions. Click the Add IP Pool button. Provide a name, and description, and enter the IP address range.

Next, we need to couple this new range with our AWS Cloud Connectors. To do that, navigate to the DNS Policies menu under Forwarding. Click Add DNS Filtering Rule. Provide a name and set the rule priority accordingly. Under the General tab, we’ll choose our AWS Cloud Connector Groups. Alternatively, you could also select Locations here as well. In the Action dropdown, select Resolve by ZPA. Then, select your new IP Pool. That’s it. AWS Cloud Connector locations using ZPA will now utilize 10.253.0.0/16 as their synthetic IP range for proxying traffic.

– Traffic forwarding intelligence can be built into the Cloud Connector appliance through Policy Management in the Cloud Connector Portal.

– Three policy types exist for Logging, DNS, and Data Plane traffic

– Each policy has an ordered list of rules with respective match criteria to define what traffic should adhere to the configured action

– Traffic Forwarding Policies allow the Cloud Connector to granularly direct traffic to ZIA, ZPA or directly out the local interface for cloud-native services

– DNS Policies allow the administrator to influence ZPA DNS requests. DNS Requests can be allowed through, denied, or resolved by ZPA. When resolved by ZPA, DNS Policies allow the administrator to customize the Synthetic IP range used for proxying traffic

1 Like