Use this template to add NAT map rules to all the appliances that support Network Address Translation.
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.
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.
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: 4000-5000). The default (no-NAT) policy is numbered 65535.
The NAT policy map has the following criteria and Set Actions:
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, and Traffic Behavior.
To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.
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.
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 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. The correct way to specify this range is 10.130-139.*.64-94.
The same rules apply to IPv6 addressing.
CIDR notation and (Range or Wildcard) are mutually exclusive in the same address. For example, use either 192.168.0.0/24 or 192.168.0.1-127.
These prefix-matching rules only apply to the following policies: Router, QoS, Optimization, NAT, Security, and ACLs.
|no-nat||Is the default. No IP addresses are changed.|
|source-nat||Is the default. No IP addresses are changed.|
|inbound||NAT is on the LAN interface.|
|outbound||NAT is on the WAN interface.|
|none||Only option if the NAT type is no-nat.|
|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.
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),
Replace (recommended) to replace all values with those in the template.