SNATs

When the default route on the servers does not route responses back through the BIG-IP system, you can create a secure network address translation (SNAT). A secure network address translation (SNAT) ensures that server responses always return through the BIG-IP^® system. You can also use a SNAT to hide the source addresses of server-initiated requests from external devices.

For inbound connections from a client, a SNAT translates the source IP address within packets to a BIG-IP system IP address that you or the BIG-IP system defines. The destination node then uses that new source address as its destination address when responding to the request.

For outbound connections, 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.

If you want the system to choose a SNAT translation address for you, you can select the Auto Map feature. If you prefer to define your own address, you can create a SNAT pool and assign it to the virtual server.

In the most common client-server network configuration, the Local Traffic Manager™ 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 node’s 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 node’s 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 node’s default gateway.

When using the OneConnect feature

Local Traffic Manager OneConnect™ 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.

This image shows a typical problem for client-initiated connections when Local Traffic Manager is not defined as the server’s default gateway, and you have not configured a SNAT for inbound traffic.

Client rejects response due to non-matching destination and source IP addresses

To prevent these problems, you can configure an inbound SNAT. An inbound SNAT translates the original client source IP address in a request to a BIG-IP system virtual server or BIG-IP system self IP address, forcing subsequent server response to return directly to Local Traffic Manager. When an inbound SNAT is configured on the system, Local Traffic Manager translates not only the destination IP address in the request (using the standard address translation mechanism), but also the source IP address in the request (using a SNAT).

The figure below shows that by configuring a SNAT, you ensure that the response returns through the BIG-IP system instead of through the default gateway, thus ensuring that the client can accept the server response.

Client accepts response due to matching destination and source IP addresses

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.

In this example of an outgoing SNAT, Local Traffic Manager causes three internal nodes, with the IP addresses 172.16.20.4, 172.16.20.5, and 172.16.20.6, to advertise the public IP address 207.10.1.102 as the source IP address in the three outgoing connections.

Sample SNAT for multiple outgoing connections

When you create a SNAT, you map an original IP address to a translation address in one of several ways, depending on your needs:

You can explicitly map one or more original IP addresses to a single translation address.

See figure

You can use the SNAT automap feature.

The SNAT automap feature automatically selects one of the system’s self IP addresses (typically a floating self IP address of the egress VLAN), and maps it to the original IP address or addresses that you specify during SNAT creation. Note that if no floating self IP address is currently assigned to the egress VLAN, the system uses the floating IP address of a non-egress VLAN.

You can create a pool of translation addresses and map one or more original IP addresses to that SNAT pool.

This pool of addresses is known as a SNAT pool. You can map an original IP address to the SNAT pool by either creating a SNAT object or writing an iRule

You can create a SNAT pool and map all original IP addresses to that SNAT pool.

Yet another way to create a SNAT is to create a SNAT pool (using the New SNAT Pool screen of the BIG-IP Configuration utility) and directly assign it to a virtual server as a resource of that virtual server. Once you have assigned a SNAT pool to a virtual server, Local Traffic Manager™ automatically maps all original IP addresses coming through the virtual server to that SNAT pool.

The types of SNATs you can create are:

Standard SNAT

A standard SNAT is an object you create, using the BIG-IP 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.

You can specify the translation addresses that you want to map to your original IP addresses. A translation address can be in these three forms:

An IP Address

When creating a SNAT, you can specify a particular IP address that you want the SNAT to use as a translation address.

A SNAT pool

Specifying this value allows you to specify an existing SNAT pool to which you want to map your original IP address.

SNAT automap

Similar to a SNAT pool, the SNAT automap feature allows you to map one or more original IP addresses to a pool of translation addresses. With the SNAT automap feature, you do not need to create the pool. Instead, Local Traffic Manager™ effectively creates a pool for you, using self IP addresses as the translation addresses for the pool.

You can specify the original IP addresses that you want to map to translation addresses. You can specify one IP address or multiple IP addresses.

You can specify one or more VLANs to which you want the SNAT to apply.