SaaS NAT Policies Tab

Configuration > Templates & Policies > Policies > SaaS NAT Policies

This report has two views that show the SaaS NAT policies configured on appliances:

• The Basic view shows whether NAT is enabled on all Inbound and Outbound.

  

• The Advanced view displays all the NAT map rules.

  

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

• These are universal across all policy maps—Route, QoS, Optimization, NAT (Network Address Translation), and Security.

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

• The available parameters are Application, Address Map (for sorting by country, IP address owner, or SaaS application), Domain, Geo Location, Interface, Protocol, DSCP, IP/Subnet, Port, Traffic Behavior Overlay, Fabric or Internet, and User Role (the User Role as specified in the authentication exchange with the ClearPass RADIUS server).

  NOTE: User Role options include the RADIUS User Role, User Name, User Group, User Device, or User MAC. Configuring User Role match criteria enables an EdgeConnect to automatically assign traffic steering and firewall zone policies.

• To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

  NOTE: Source and destination role-based policies can be configured 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

NAT Direction

NAT IP

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.

SaaS NAT Policies Edit Row

This report has two views that show the SaaS NAT policies configured on appliances:

• The Basic view shows whether NAT is enabled on all Inbound and Outbound.

• The Advanced view displays all the NAT map rules.

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

• These are universal across all policy maps—Route, QoS, Optimization, NAT (Network Address Translation), and Security.

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

• The available parameters are Application, Address Map (for sorting by country, IP address owner, or SaaS application), Domain, Geo Location, Interface, Protocol, DSCP, IP/Subnet, Port, Traffic Behavior Overlay, Fabric or Internet, and User Role (the User Role as specified in the authentication exchange with the ClearPass RADIUS server).

  NOTE: User Role options include the RADIUS User Role, User Name, User Group, User Device, or User MAC. Configuring User Role match criteria enables an EdgeConnect to automatically assign traffic steering and firewall zone policies.

• To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

  NOTE: Source and destination role-based policies can be configured 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

NAT Direction

NAT IP

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.

---