Applies To:

Show Versions Show Versions

Manual Chapter: SNATs
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

16 
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.
To configure and manage SNATs, log in to the BIG-IP Configuration utility, and on the Main tab, expand Local Traffic, and click SNATs.
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.
By default, SNATs support UDP and TCP only. This makes a SNAT more secure than a NAT.
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.
Table 16.2 shows the settings that you can configure for a SNAT. Following the table are detailed descriptions of each setting.
Depending on the value selected, specifies an individual IP address, a SNAT pool name, or the Automap option. Possible values are: IP Address, SNAT Pool, or Automap.
Specifies the original IP addresses to which you want to map a translation address or pool of translation or self IP addresses. Possible values are All Addresses or Address List.
Table 16.3 lists and describes the properties of a translation address.
The state of the translation address, that is, enabled or disabled. If set to disabled, the translation address is not used to initiate a connection.
A limit on the number of connections a translation address must reach before it no longer initiates a connection. The default value of 0 indicates that the setting is disabled.
TCP Idle Timeout
A timer that defines the number of seconds that TCP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected. Possible values are Indefinite or Specify.
UDP Idle Timeout
A timer that defines the number of seconds that UDP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected. Possible values are Indefinite or Specify.
A timer that defines the number of seconds that IP connections initiated using a SNAT address are allowed to remain idle before being automatically disconnected. Possible values are Indefinite or Specify.
The list of IP addresses that you want to include in SNAT pool. If the IP addresses that you add are not already designated as translation addresses, the BIG-IP system automatically designates them as such and assigns them the appropriate properties with their default values. This setting is required.
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:
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.
Note: Using a SNAT for inbound connections can impact the availability of ephemeral ports. This can lead to the SNAT being unable to process additional connections until some source ports become available.
Figure 16.1 shows a typical problem for client-initiated connections when Local Traffic Manager is not defined as the servers default gateway, and you have not configured a SNAT for inbound traffic.
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).
Figure 16.2, 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.
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.
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.
Figure 16.3 shows an example of an outgoing SNAT. In this example, 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.
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 use the SNAT automap feature.
The SNAT automap feature automatically selects one of the systems 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 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.
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:
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.
The following examples demonstrate ways to implement SNATs that make use of SNAT pools. The examples illustrate how you can:
In some cases, you might need to create a SNAT that maps an original IP address to a SNAT pool instead of to an individual translation address. To illustrate this type of SNAT, suppose an Internet service provider (ISP) has a BIG-IP system and wants to provide two customers with two routable IP addresses each, for links to the Internet. The customers need to use these routable IP addresses as virtual IP addresses for inbound traffic to their own servers, and as translation addresses for outbound traffic from their servers.
Figure 16.4 bigip.conf entries for a basic load balancing pool
pool isp_pool {
lb_method rr
member 199.5.6.254:0
member 207.8.9.254:0
}
Next, the ISP creates three SNAT pools: customer1_snatpool, customer2_snatpool, and other_snatpool. This is shown in Figure 16.5. Note that Local Traffic Manager automatically designates the SNAT pool members as translation addresses.
Figure 16.5 bigip.conf entries for three SNAT pools
snatpool customer1_snatpool {
member 199.5.6.10
member 207.8.9.10
}
snatpool customer2_snatpool {
member 199.5.6.20
member 207.8.9.20
}
snatpool other_snatpool {
member 199.5.6.30
member 207.8.9.30
}
Finally, using the Configuration utility, the ISP creates a SNAT that maps each original IP address directly to the appropriate SNAT pool.
If you want to base SNAT mapping on criteria other than the original IP address, such as a server port, you can write an iRule and specify a SNAT pool within the iRule. In this case, you use the SNAT screens in the Configuration utility to create a SNAT pool only, and not an actual SNAT object.
For example, suppose a user such as an ISP has two redundant connections to the Internet. In addition, the ISP handles many simultaneous CHAT connections (using port 531), and wants to avoid exhausting the supply of server-side client ports. Finally, the ISP wants to collect statistics separately for CHAT, SMTP, and all other traffic. In this case, configuring an intelligent SNAT is the best way to choose the translation address.
First, the ISP creates a load balancing pool called out_pool. In the bigip.conf file, the pool looks like the sample in Figure 16.6.
Figure 16.6 bigip.conf entries for a pool to be used in an intelligent SNAT
pool out_pool {
lb_method round_robin
member 199.5.6.254:0
member 207.8.9.254:0
}
Next, as shown in Figure 16.7, the ISP uses the Configuration utility to create a SNAT pool called chat_snatpool containing four IP addresses: 199.5.6.10, 199.5.6.11, 207.8.9.10, and 207.8.9.11. Local Traffic Manager automatically designates these IP addresses as translation addresses during creation of the SNAT pool. These addresses correspond to each of the two next hop networks that are to be used for CHAT traffic. In the bigip.conf file, the SNAT pool looks like the sample in Figure 16.7.
snatpool chat_snatpool {
member 199.5.6.10
member 199.5.6.11
member 207.8.9.10
member 207.8.9.11
}
Next, for each translation address, the ISP uses the Configuration utility to change the timeout value for TCP connections to 600.
Then the ISP creates a second SNAT pool, smtp_snatpool containing two translation addresses: 199.5.6.20 and 207.8.9.20. Each address corresponds to one of the two next hop networks that are to be used for SMTP traffic. In the bigip.conf file, the SNAT pool looks like the sample in Figure 16.8.
snatpool smtp_snatpool {
member 199.5.6.20
member 207.8.9.20
}
Next, the ISP creates the SNAT pool other_snatpool for all other traffic (that is, non-CHAT and non-SMTP traffic), where each IP address corresponds to one of the two next hop networks that are to be used by all other traffic. This is shown in Figure 16.9.
snatpool other_snatpool { \SNAT pool definition
member 199.5.6.30
member 207.8.9.30
}
Then the ISP writes an iRule that selects both a SNAT pool, based on the server port of the initiating packet, and the load balancing pool out_pool. Figure 16.11 shows how the iRule specifies the command TCP::local_port to indicate the type of packet data to be used as a basis for selecting translation addresses. The iRule also shows the command snatpool (shown in Figure 16.10) to specify the SNAT pools from which Local Traffic Manager is to select the translation addresses.
rule my_iRule {
when SERVER_CONNECTED
if ( TCP::local_port equals 531 ) {
snatpool chat_snatpool
}
else if ( TCP::local_port equals 25 ) {
snatpool smtp_snatpool
}
else {
snatpool other_snatpool
}
pool out_pool
}
The if statement in the iRule instructs Local Traffic Manager to test the value of server port specified in the header of the client request. Based on the results, Local Traffic Manager selects both a SNAT pool and a load balancing pool.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)