Manual Chapter :
NATS and SNATs
Applies To:
Show VersionsBIG-IP AAM
- 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP APM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP Analytics
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP Link Controller
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP LTM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP PEM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP AFM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP DNS
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP ASM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
NATS and SNATs
Introduction to NATs and SNATs
You can configure the BIG-IP® system to translation IP addresses in packets
that pass through the system. You can configure objects for both network address translation
(NATs) and source network address translation (SNATs).
Comparison of NATs and SNATs
A SNAT is similar to a NAT, except for the differences listed in this
table.
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 node’s
traffic arrives on the BIG-IP system. |
By default, a SNAT that you create is enabled on all VLANs. |
About NATs
In some cases, you might want to allow a client on an external network to
send a request directly to a specific internal node (thus bypassing the normal load balancing
server selection). To send a request directly to an internal server, a client normally needs to
know the internal node’s IP address, which is typically a private class IP address. Because
private class IP addresses are non-routable, you can instead create a network translation address
(NAT). A
NAT
is a feature of BIG-IP
Local Traffic Manager that provides a routable IP address
that an external node can use to send traffic to, or receive traffic from, an internal node.More specifically, a NAT is an address translation object that instructs
Local Traffic Manager (LTM) to translate one IP address
in a packet header to another IP address. A NAT consists of a one-to-one mapping of a public IP
address to an internal private class IP address.
You can use a NAT in two different ways:
- To translate a private class destination address to a public address
- When an external node sends traffic to the public IP address defined in a NAT, Local Traffic Manager automatically translates that destination address to the associated private class IP address, which represents a specific node on the internal network. This translation is hidden from the external node that sent the traffic.
- To translate a private class source address to a public address
- You can also use a NAT to translate an internal node’s private class source IP address to a public IP address. This translation is hidden from the external node that receives the traffic.
To summarize, a NAT provides a routable address for sending packets to or
from a node that has a private class IP address.
When you create a NAT, you can map only one private class IP address to a
specific public IP address. That is, a NAT always represents a one-to-one mapping between a
private class IP address and a public IP address. If you want to map more than one private class
IP address (that is, multiple internal nodes) to a single public IP address, you can create a
SNAT instead.
NATs do not
support port translation, and are not appropriate for protocols that embed IP addresses in the
packet, such as FTP.
When you use
a NAT to provide access to an internal node, all ports on that internal node are open. To
mitigate this security risk, consider using a SNAT instead.
Local Traffic Manager can apply a NAT to either an inbound or an outbound
connection.
NATs for inbound connections
With respect to NATs, an
inbound
connection is a connection that is initiated by a
node on an external network, and comes into the BIG-IP® system to a node
on the internal network.Without a NAT
Normally, traffic coming into the BIG-IP system is load balanced to a server in a pool, based on the load balancing method configured for that pool, in the following way:
- A client on an external network typically sends traffic to a virtual server on the BIG-IP system. The destination IP address in this case is the virtual server address.
- Upon receiving a packet, the virtual server typically translates that destination IP address to the IP address of a pool member, for the purpose of load balancing that packet.
- The pool member then sends its response back through the BIG-IP system, using a route specified in the server node’s routing table (ideally, a floating IP address assigned to an internal VLAN). On receiving the response, Local Traffic Manager then performs the reverse translation; that is, the system translates the pool member’s actual source address to the virtual server address. This results in the source address in the response to the client being the virtual server address, which is the source address that the client expects to see.
This typical load balancing scenario ensures that for load balanced traffic, the client system never sees the internal private class IP address of an internal node.
With a NAT
If the client system wants to bypass the load balancing mechanism to send packets directly to a specific node on the internal network, the client needs a routable IP address to use to send packets to that server node.
A NAT solves this problem by providing a routable address that a client can use to make a request to an internal server directly. In this way, a NAT performs the same type of address translation that a virtual server performs when load balancing connections to pool members. In the case of a NAT, however, no load balancing occurs, because the client is sending a request to a specific node. The NAT translates the public destination IP address in the request to the private class IP address of the internal node.
When the server node sends the response, Local Traffic Manager performs the reverse translation, in the same way that a virtual server behaves.
Local Traffic Manager does not track NAT connections. Therefore, the public IP address that you define in a NAT cannot be the same address as a virtual address or SNAT address.
For example, suppose a node on the internal network (such as a load balancing server) has a private class IP
address of
172.16.20.3
. You can create a NAT designed to translate a
public destination address of your choice (such as 207.10.1.103
) to the
private class address 172.16.20.3
. Consequently, whenever a node on the
external network initiates a connection to the address 207.10.1.103
,
Local Traffic Manager translates that public destination address to the private class address
172.16.20.3
.In this example, the NAT provides a routable address for an external node to initiate a connection to an internal node.
When you create a NAT, you must define two settings: NAT Address and Origin Address. In our
example:
- The NAT address is207.10.1.103, and the origin address is172.16.20.3.
- The connection is an inbound connection, meaning that the connection is being initiated from the external network, through the BIG-IP system, to the internal network.
- Local Traffic Manager translates the NAT address to the origin address.
- The NAT address and the origin address are destination addresses.
NATs for outbound connections
The previous section summarized how a BIG-IP® system normally load
balances incoming traffic, and translates the source IP address in a response back to the
virtual address.
Sometimes, however, an internal node needs to initiate a connection, rather than simply respond
to a request. When a node on an internal network initiates a connection, the connection is
considered to be an
outbound
connection. In this case, because the outgoing packets
do not represent a response to a load-balanced request, the packets do not pass through a virtual
server, and therefore the system does not perform the usual source IP address translation.Without a NAT, the source IP address is a non-routable address. With a NAT, however, Local Traffic Manager translates the internal node’s private class IP
address to a public IP address, to which the external node can then route its response.
For example, suppose an internal node (such as a mail server) has a private class IP address
of
172.16.20.1
. You can create a NAT designed to translate the private
class address 172.16.20.1
to a public source address of your choice
(such as 207.10.1.101
). Consequently, whenever the internal node
172.16.20.1
initiates a connection destined for a node on the
external network, the system translates that source address of
172.16.20.1
to its public address
(207.10.1.101
).In this example, the NAT provides a way for an internal node to initiate a connection to a node on an external network, without showing a private class IP address as the source address.
A NAT has two settings;
NAT Address
and Origin
Address
. In this example:- The NAT address is207.10.1.101, and the origin address is172.16.20.1.
- The connection is an outbound connection, meaning that the connection is being initiated from the internal network, through Local Traffic Manager, to the external network.
- Local Traffic Manager translates the origin address to the NAT address.
- The origin address and the NAT address are source addresses.
A NAT always represents a one-to-one mapping between a public address and a private class address. However, if you would like to map multiple internal nodes to a single public address, you can use a secure network translation address (SNAT) instead of a NAT. You can use SNATs for outbound connections only.
Creating a NAT
You enable network address translation (NAT) so that the BIG-IP system can translate one IP address to another.
- On the Main tab, click.This displays a list of NATs on the system.
- Click theCreatebutton.
- In theNamefield, type a name for the NAT.
- In theNAT Addressfield, type the IP address that you want to use as the translation address, that is, the address to which you want to translate the origin address.
- In theOrigin Addressfield, type the IP address of the node that you want traffic to reach when the BIG-IP system applies the NAT address.
- Configure the remaining settings or retain the default values.
After you perform this task, the NAT appears in the list of NATs on the
system.
About SNATs
When you need to ensure that server responses always return through the BIG-IP® 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 Manager 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 server’s 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.
F5 recommends that before implementing a SNAT, you understand NATs.
SNATs for client-initiated (inbound) connections
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 asvirtual 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.
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.
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.
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.
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:
- 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.
- 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.
- 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.SNAT types
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 the BIG-IP™ system 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 the BIG-IP system 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
- 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.
- 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.
About translation addresses
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.
Original IP addresses
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.
VLAN traffic
You can specify one or more VLANs to which you want the SNAT to apply.
About ephemeral port
exhaustion
When you use a secure network address translation (SNAT) for
client-initiated (inbound) connections, the availability of ephemeral ports can become diminished
and possibly exhausted, resulting in an inability of the SNAT to process additional connections
until source ports again become available. You can configure the BIG-IP system to accumulate real-time ephemeral-port statistics, and
when usage exceeds a specified threshold level, to log an error and provide a Simple Network
Management Protocol (SNMP) alert notification, thus enabling you to assess an approaching
exhaustion of ephemeral ports and respond accordingly.
When configuring ephemeral port exhaustion functionality, you can enable the
port exhaustion threshold, specify a threshold trigger level, and specify a timeout duration in
seconds. The following commands apply default values.
# tmsh modify ltm global-settings traffic-control port-find-threshold-warning enabled # tmsh modify ltm global-settings traffic-control port-find-threshold-trigger 8 # tmsh modify ltm global-settings traffic-control port-find-threshold-timeout 30
You can view a summary of the traffic control settings by typing the
following command at the command line:
tmsh list
ltm global-settings traffic-control all-properties
. Note that you need to configure logging functionality, for example,
high-speed remote logging, to log any ephemeral port exhaustion error messages. Additionally, you
will want to manage any alert notifications by using SNMP.
Ephemeral port reference
This topic summarizes the settings available for notification of ephemeral port
exhaustion.
Traffic-Control Parameter |
Default Value |
Description |
---|---|---|
port-find-threshold-warning |
enabled |
Enables or disables ephemeral port-exhaustion threshold warning
functionality. |
port-find-threshold-trigger |
8 |
Specifies the number of attempts to find an unused outbound port for a
connection, beyond which the probability of port exhaustion signficantly increases.
Values can range from 1 through
12 . |
port-find-threshold-timeout |
30 |
Specifies the period, in seconds, from one threshold trigger until a subsequent
threshold trigger. If the value for this period is exceeded, the threshold warning
expires and resets. Values can range from 0 through
300 seconds. |
Creating a SNAT
A
secure network address translation (SNAT)
is a BIG-IP 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. - On the Main tab, click.TheSNAT Listscreen displays a list of existing SNATs.
- ClickCreate.
- Name the new SNAT.
- From theTranslationlist, select a translation type to use.
- From theVLAN / Tunnel Trafficlist, selectEnabled on.
- For theVLAN / Tunnel Listsetting, in theAvailablelist, selectexternalandinternal, and using the Move button, transfer the VLANs to theSelectedlist.
- From theAuto Last Hoplist, select a value or retain the default value,Default.SelectingDefaultcauses the BIG-IP system to behave according to the value of the system-wideAuto Last Hopsetting, rather than enablingAuto Last Hopfor this SNAT only.
- Click theFinishedbutton.
After you perform this task, the SNAT appears in the list of SNATs on the
system.
You must assign the SNAT to a virtual server.
Creating a SNAT pool
You create a SNAT pool on the BIG-IP system to identify IP
addresses that you want the BIG-IP system to use as a SNAT translation address.
In a device service clustering configuration, you perform this task on
only one device in the device group. You will later synchronize this configuration
to the other devices in the device group.
- On the Main tab, click.The SNAT Pool List screen displays a list of existing SNATs.
- ClickCreate.
- In theNamefield, type a name for the SNAT pool.An example of a name issnat-pool-1.
- For theMember Listsetting:
- In theIP Addressfield, type an IP address.The BIG-IP system uses this address as a SNAT translation address.
- ClickAdd.
- Repeat these steps for each IP address that you want to include in the SNAT pool.
- Click theFinishedbutton.
After you perform this task, a SNAT pool resides on the BIG-IP system.
To enable the SNAT pool, you must assign the SNAT pool to a SNAT object, or specify
the SNAT pool within an iRule.