SaaS NAT Policies Template

Use this template to add NAT map rules to all the appliances that support Network Address Translation.

When to NAT

Two use cases illustrate the need for NAT:

Inbound NAT. The appliance automatically creates a source NAT (Network Address Translation) map when retrieving subnet information from the Cloud Portal. This ensures that traffic destined to SaaS servers has a return path to the appliance from which that traffic originated.
Outbound NAT. The appliance and server are in the cloud, and the server accesses the internet. As in the example below, a Citrix thin client accesses its cloud-based server, and the server accesses the internet.

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

Enabling NAT all applies NAT policies to pass-through traffic as well as optimized traffic, ensuring that black-holing does not occur. NAT all on outbound only applies pass-through traffic.
If Fallback is enabled, 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 of the subnets 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 the following criteria and Set Actions:

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	Is the default. No IP addresses are changed.
source-nat	Is the default. No IP addresses are changed.

NAT Direction

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

NAT IP

Option	Description
auto	Select if you want to NAT all traffic. The appliance then picks the first available NAT IP/Port.
tunnel	Select if you want to NAT tunnel traffic only. Applicable only for inbound NAT, as outbound does not support NAT on tunnel traffic.
[IP address]	Select if you want to make NAT use this IP address 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, ensure that the routing is in place for NAT-ted return traffic.

Merge / Replace

At the top of the page, choose

Merge to use the values in the template, but keep any values set on the appliance as is (producing a mix of template and appliance rules),

-OR-

Replace (recommended) to replace all values with those in the template.