SaaS NAT Policies Tab

Configuration > Templates & Policies > Policies > SaaS NAT Policies

Use the SaaS NAT Policies tab to view Network Address Translation (NAT) policies (specifically, for SaaS applications) that exist on the appliances selected in the appliance tree. These policies define how SaaS traffic is handled, ensuring optimal performance, security, and compliance.

The tab has two views that show SaaS NAT policies configured on selected appliances:

  • Basic: Indicates whether NAT is enabled on all inbound and outbound traffic. This view also indicates whether fallback is enabled for inbound and outbound traffic. If enabled, the appliance moves to the next IP (if available) when ports are exhausted on the current NAT IP.

  • Advanced: Shows all configured NAT map rules. To display dynamically created NAT policies that are automatically generated based on SaaS traffic behavior and predefined rules, select the Show Dynamic Policies check box. These dynamic policies are created in real time to handle specific SaaS traffic flows as needed.

To directly configure and manage SaaS NAT policies for a particular appliance, click the associated edit icon from either view. To create and manage SaaS NAT policies with a template, click Manage SaaS NAT Policies with Templates.

For details about fields on this tab, see SaaS NAT Policies Dialog Box below.

SaaS NAT Policies Dialog Box

Use the SaaS NAT Policies dialog box to directly configure and manage SaaS NAT policies for a particular appliance.

When to NAT Traffic

Two use cases illustrate the need to NAT traffic:

  • Inbound NAT: The appliance automatically creates a source NAT map when retrieving subnet information from the Cloud Portal. This ensures that traffic going to SaaS servers has a return path to the appliance from which that traffic originated.

    img

  • Outbound NAT: The appliance and server are in the cloud, and the server accesses the internet. In the following example, a Citrix thin client accesses its cloud-based server, and the server accesses the internet.

    img

For deployments in the cloud, the best practice is to NAT all traffic—either inbound (WAN-to-LAN) or outbound (LAN-to-WAN), depending on the direction of the initiating request. This avoids blackholing, which can result from cloud-specific IP addressing requirements.

  • Enabling NAT all applies NAT policies to passthrough traffic as well as optimized traffic, ensuring that blackholing does not occur. Using NAT all on outbound applies NAT policies to passthrough traffic only.

  • If you enable Fallback, the appliance moves to the next IP (if available) when ports are exhausted on the current NAT IP.

In general, when applying NAT policies, configure separate WAN and LAN interfaces to ensure that NAT works properly. You can do this by deploying the appliance in Router mode in-path with two (or four) interfaces.

Advanced Settings

The appliance can perform source network address translation (Source NAT or SNAT) on inbound or outbound traffic.

There are two types of NAT policies:

  • Dynamic: Created automatically by the system for inbound NAT when the SaaS Optimization feature is enabled and SaaS service(s) are selected for optimization. The appliance polls the Cloud Intelligence Service for a directory of SaaS services, and NAT policies are created for each subnet associated with selected SaaS service(s), ensuring that traffic destined for servers in use by those SaaS services has a return path to the appliance. Dynamic policy numbering assigns priority numbers (in the range 40000 to 50000) to individual policies within a NAT map. The default (no-NAT) policy is numbered 65535.

  • Manual: Created by the administrator for specific IP addresses / ranges or subnets. When assigning priority numbers to individual policies within a NAT map, first view dynamic policies to ensure that the manual numbering scheme does not interfere with dynamic policy numbering (that is, the manually assigned priority numbers cannot be in the range 40000 to 50000). The default (no-NAT) policy is numbered 65535.

The NAT policy map has match criteria and set actions, which are described below.

Match Criteria

Match criteria are used universally across all policy maps for route, QoS, optimization, SaaS NAT, and firewall zone security policies.

To use the same match criteria in different maps, create an ACL (Access Control List), which is a named, reusable set of rules. For efficiency, navigate to Configuration > Templates & Policies > ACLs > Access Lists to create ACLs, and then apply them across your appliances.

Use the Match Criteria dialog box to select and configure a variety of match criteria options. Some are explained below:

  • Address Map: Use this option to sort by country, IP address owner, or SaaS application. You can also select and configure Microsoft Instance, Microsoft Category, and Proxy attributes for an address map. These attributes are secondary parameters to the address map. They are evaluated for a policy match only when the configured address map matches the flow. To select and configure these attributes, click +Attributes.

  • Match criteria options related to Secure Web Services include:

    • URL: Omit the protocol in URLs and include a slash character (/) or a slash followed by a query parameter. For example, google.com/ or google.com/maps are valid; https://google.com/ is not valid. You can also use the asterisk (*) wildcard character, such as in google.com/*, to specify a domain, but it is more appropriate to use the Domain match criteria option to specify google.com/. Separate multiple URL addresses with the pipe character (|). For example, you can specify two URL addresses as bing.com/*|google.com/*.

    • Web Category: If you select this option, click Select, and then click Strict, Moderate, or Custom. Strict and Moderate include predetermined web category selections, which you cannot change. However, if you attempt to select or clear a web category for these, the Custom group of web category selections opens automatically. You can customize web category selections in the Custom group. After you make your selections, click Ok.

    • Web Reputation: If you select this option, select one or more web reputation categories (High Risk, Suspicious, Moderate Risk, Low Risk, or Trustworthy) from the list. To select more than one, press and hold the Shift key, and then click the appropriate categories.

    • Bad IP Reputation: Selecting this option matches on flows for which the source or destination IP address (or both) has a High Risk reputation score.

  • Match criteria options related to RADIUS user role include:

    • User Role: This is the user role as specified in the authentication exchange with the ClearPass RADIUS server.

    • User Name

    • User Group

    • User Device

    • User MAC

    • User Vlan

    Configuring these match criteria related to user role enables an EdgeConnect to automatically assign traffic steering and firewall zone policies.

  • Use the Src:Dest check box associated with several match criteria options to specify separate criteria for inbound and outbound traffic. You can configure source and destination role-based policies when both source and destination users are in the same network.

Source or Destination

  • An IP address can specify a subnet; for example, 10.10.10.0/24 (IPv4) or fe80::204:23ff:fed8:4ba2/64 (IPv6).

  • To allow any IP address, use 0.0.0.0/0 (IPv4) or ::/0 (IPv6).

  • Ports are available only for the protocols tcp, udp, and tcp/udp.

  • To allow any port, use 0.

Wildcard-based Prefix Matching Rules

  • Even when using a range or a wildcard, the IPv4 address must be specified in the 4-octet format, separated by the dot notation. For example, A.B.C.D.

  • Range is specified using a single dash. For example, 128-129.

  • Wildcard is specified as an asterisk (*).

  • Range and Wildcard can both be used in the same address, but an octet can only contain one or the other. For example, 10.136-137.*.64-95.

  • A wildcard can only be used to define an entire octet. For example, 10.13*.*.64-95 is not supported. Use 10.130-139.*.64-95 to specify this range.

  • The same rules apply to IPv6 addressing.

  • CIDR notation and (Range or Wildcard) are mutually exclusive in the same address. For example, 192.168.0.1-127/24 is not supported. Use either 192.168.0.0/24 or 192.168.0.1-127.

  • These prefix-matching rules apply to the following policies only: Route, QoS, Optimization, NAT, Security, and ACLs.

Set Actions

NAT Type

Option Description
no-nat This is the default setting. No IP addresses are changed.
source-nat The appliance performs Source NAT on inbound or outbound traffic.

NAT Direction

Option Description
inbound NAT is on the LAN interface.
outbound NAT is on the WAN interface.
none This is the only option if the NAT type is no-nat.

NAT IP

Option Description
auto Select to NAT all traffic. The appliance picks the first available NAT IP/port.
tunnel Select to NAT tunnel traffic only. Applicable only for inbound NAT because outbound does not support NAT on tunnel traffic.
[IP address] Select a listed IP address to make NAT use it during address translation.

For fallback, if the IP address is full, the appliance uses the next available IP address.

When you select a specific IP address, ensure that the routing is in place for NAT-ted return traffic.