SNAT

When you need to ensure that server responses always return through the BIG system, or when you want to hide the source addresses of server-initiated requests from external devices, you can implement a SNAT. A secure network address translation (SNAT) is a BIG-IP® Local Traffic ManagerTM feature that translates the source IP address within a connection to a BIG-IP system IP address that you define. The destination node then uses that new source address as its destination address when responding to the request. For inbound connections, that is, connections initiated by a client node, SNATs ensure that server nodes always send responses back through the BIG-IP system, when the servers default route would not normally do so. Because a SNAT causes the server to send the response back through the BIG-IP system, the client sees that the response came from the address to which the client sent the request, and consequently accepts the response.
For outbound connections, that is, connections initiated by a server node, SNATs ensure that the internal IP address of the server node remains hidden to an external host when the server initiates a connection to that host.

NATs	SNATs
You can map only one original address to a translation address,	You can map multiple original addresses to a single translation address. You can even map all node addresses on your network to a single public IP address, in a single SNAT object.
All ports on the internal node are open.	By default, SNATs support UDP and TCP only. This makes a SNAT more secure than a NAT.
Local Traffic Manager does not track NAT connections.	Local Traffic Manager tracks SNAT connections, which, in turn, allows SNATs and virtual servers to use the same public IP addresses.
You must explicitly enable a NAT on the internal VLAN where the internal nodes traffic arrives on the BIG-IP system.	By default, a SNAT that you create is enabled on all VLANs.

SNATs for client-initiated (inbound) connections

In the most common client-server network configuration, Local Traffic Managers standard address translation mechanism ensures that server responses return to the client through the BIG-IP system, thereby reversing the original destination IP address translation. This typical network configuration is as follows:

The server nodes are on the same subnet as the BIG-IP system.
The client nodes are on a different subnet from the server nodes.
The BIG-IP system is the default gateway for the server subnet.

However, there are atypical network configurations in which the standard BIG-IP system address translation sequence by itself does not ensure that server responses use the required return path. Examples of these atypical configurations are:

When clients and servers are on the same network
If you want to load balance requests to server nodes that are on the same network as the client nodes, you can create a SNAT so that server responses are sent back through the virtual server, rather than directly from the server node to the client node. Otherwise, problems can occur such as the client rejecting the response because the source of the response does not match the destination of the request. Known as virtual server bounceback, this SNAT configuration causes the source of the response to match the destination of the request, thus ensuring that the client node accepts the response. You can use this kind of configuration when you want to load balance requests from web servers to application servers on the same network.
When the default gateway of the server node is not the BIG-IP system
For various reasons, the server nodes default route cannot always be defined to be a route back through the BIG-IP system. Again, this can cause problems such as the client rejecting the response because the source of the response does not match the destination of the request.The solution is to create a SNAT. When Local Traffic Manager then translates the client nodes source IP address in the request to the SNAT address, this causes the server node to use that SNAT address as its destination address when sending the response. This, in turn, forces the response to return to the client node through the BIG-IP system rather than through the server nodes default gateway.
When using the OneConnect feature
Local Traffic Manager OneConnectTM feature allows client requests to re-use idle server-side connections. Without a SNAT, the source IP address in the server-side connection remains the address of the client node that initially established the connection, regardless of which other client nodes re-use the connection. Although this is not an issue for traffic routing, you might find it confusing when examining various types of system output. A SNAT solves this problem.

SNATs for server-initiated (outbound) connections

When an internal server initiates a connection to an external host, a SNAT can translate the private, source IP addresses of one or more servers within the outgoing connection to a single, publicly-routable address. The external destination host can then use this public address as a destination address when sending the response. In this way, the private class IP addresses of the internal nodes remain hidden from the external host.
More specifically, a SNAT for an outgoing connection works in the following way:
1.Local Traffic Manager receives a packet from an original IP address (that is, an internal server with a private IP address) and checks to see if that source address is defined in a SNAT.
2.If the original IP address is defined in a SNAT, Local Traffic Manager changes that source IP address to the translation address defined in the SNAT.
3.Local Traffic Manager then sends the packet, with the SNAT translation address as the source address, to the destination host.

SNAT types

The types of SNATs you can create are:

Standard SNAT
A standard SNAT is an object you create, using the Configuration utility, that specifies the mapping of one or more original IP addresses to a translation address. For this type of SNAT, the criteria that Local Traffic Manager uses to decide when to apply the translation address is based strictly on the original IP address. That is, if a packet arrives from the original IP address that you specified in the SNAT, then Local Traffic Manager translates that address to the specified translation address.
There are three types of standard SNATs that you can create:
- A SNAT in which you specify a specific translation address
- A SNAT that uses the automap feature
- A SNAT in which you specify a SNAT pool as your translation address
Intelligent SNAT
Like a standard SNAT, an intelligent SNAT is the mapping of one or more original IP addresses to a translation address. However, you implement this type of SNAT mapping within an iRule instead of by creating a SNAT object. For this type of SNAT, the criteria that Local Traffic Manager uses to decide when to apply a translation address is based on any piece of data you specify within the iRule, such as an HTTP cookie or a server port.
SNAT pool assigned as a virtual server resource
This type of SNAT consists of just a SNAT pool that you directly assign as a resource to a virtual server. When you implement this type of SNAT, you create a SNAT pool only; you do not need to create a SNAT object or an iRule.

Configuration of SNAT

From the picture you can see that you can access address translation via the LTM menu. Then there are couple of sections:

SNAT List – This is the place where you gonna configure Standard NAT. Here you specify the origin address (all addresses, specific address, list of addresses) and translated address (specific, automap, pool of addresses).
SNAT Pool list – here is the place where you can create the pool of translated ip addresses.
SNAT Translation List – this is the place where you can enhance configuration for specific translation address referred in SNAT list. You can define TCP/UDP/IP idle timeout, ARP response and traffic group. Check the picture. The name of SNAT translation IP address should match with SNAT list translated address.
NAT list – here is a place where you define regular 1:1 NAT.