Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

NAT Configuration Overview

Network Address Translation Configuration Overview

To configure network address translation (NAT), complete the following high-level steps:

  1. Configure the source and destination addresses. For more information, see Configuring Source and Destination Addresses Network Address Translation Overview.
  2. Define the addresses or prefixes, address ranges, and ports used for NAT. For more information, see Configuring Pools of Addresses and Ports for Network Address Translation Overview
  3. If applicable, configure the address pools for network address port translation (NAPT). For more information, see Configuring Address Pools for Network Address Port Translation (NAPT) Overview.
  4. Configure the NAT rules. Within the rules, include match directions, match conditions, actions, and translation types. For more information, see Network Address Translation Rules Overview.
  5. Configure service sets for NAT processing. Within each service set, define the interfaces for handling inbound and outbound traffic and a NAT rule or ruleset. For more information, see Configuring Service Sets for Network Address Translation.

See Also

Configuring Source and Destination Addresses Network Address Translation Overview

You must configure a specific address, a prefix, or the address-range boundaries:

  • The following addresses, while valid in inet.0, cannot be used for NAT translation:

    • 0.0.0.0/32

    • 127.0.0.0/8 (loopback)

    • 128.0.0.0/16 (martian)

    • 191.255.0.0/16 (martian)

    • 192.0.0.0/24 (martian)

    • 223.255.255.0/24 (martian)

    • 224.0.0.0/4 (multicast)

    • 240.0.0.0/4 (reserved)

    • 255.255.255.255 (broadcast)

    The addresses that are specified as valid in the inet.0 routing table and not supported for NAT translation are orlonger match filter types. You cannot specify any regions within such address prefixes in a NAT pool.

  • On MX Series routers with MS-MPCs and MS-MICs, if you configure a NAT address pool with a prefix length that is equal to or greater than /16, the PIC does not contain sufficient memory to provision the configured pool. Also, memory utilization problems might occur if you attempt to configure many pools whose combined total IP addresses exceed /16. In such circumstances, a system logging message is generated stating that the NAT pool name is failed to be created and that the service set is not activated. On MS-MPCs and MS-MICs, you must not configure NAT pools with prefix lengths greater than or equal to /16.

  • You can specify one or more IPv4 address prefixes in the pool statement and in the from clause of the NAT rule term. This enables you to configure source translation from a private subnet to a public subnet without defining a rule term for each address in the subnet. Destination translation cannot be configured by this method. For more information, see Examples: Configuring NAT Rules.

  • When you configure static source NAT, the address prefix size you configure at the [edit services nat pool pool-name] hierarchy level must be larger than the source-address prefix range configured at the [edit services nat rule rule-name term term-name from] hierarchy level. The source-address prefix range must also map to a single subnet or range of IPv4 or IPv6 addresses in the pool statement. Any pool addresses that are not used by the source-address prefix range are left unused. Pools cannot be shared.

  • When you configure a NAT address pool prefix size with the address statement at the [edit services nat pool nat-pool-name] hierarchy level, the subnet and broadcast addresses are not included in the list of usable IP addresses. For example, if you use address 10.11.12.0/28 in a NAT pool, the addresses 10.11.12.0 (subnet address) and 10.11.12.15 (broadcast address) are not available.

Note:

When you include a NAT configuration that changes IP addresses, it might affect forwarding path features elsewhere in your router configuration, such as source class usage (SCU), destination class usage (DCU), filter-based forwarding, or other features that target specific IP addresses or prefixes.

NAT configuration might also affect routing protocol operation, because the protocol peering, neighbor, and interface addresses can be altered when routing protocols packets transit the Adaptive Services (AS) or Multiservices PIC.

See Also

Configuring Pools of Addresses and Ports for Network Address Translation Overview

Configuring NAT Pools

You can use the pool statement to define the addresses (or prefixes), address ranges, and ports used for Network Address Translation (NAT). To configure the information, include the pool statement at the [edit services nat] hierarchy level.

Starting in Junos OS Release 14.2, configure the NAT pool as follows. Starting in Junos OS Release 16.1, the limit-ports-per-address statement is supported.

In Junos OS Release 14.1 and earlier, configure the NAT pool as follows:

To configure pools for traditional NAT, specify either a destination pool or a source pool.

With static source NAT and dynamic source NAT, you can specify multiple IPv4 addresses (or prefixes) and IPv4 address ranges. Up to 32 prefixes or address ranges (or a combination) can be supported within a single pool.

With static destination NAT, you can also specify multiple address prefixes and address ranges in a single term. Multiple destination NAT terms can share a destination NAT pool. However, the netmask or range for the from address must be smaller than or equal to the netmask or range for the destination pool address. If you define the pool to be larger than required, some addresses will not be used. For example, if you define the pool size as 100 addresses and the rule specifies only 80 addresses, the last 20 addresses in the pool are not used.

For constraints on specific translation types, see Network Address Translation Rules Overview.

With source static NAT, the prefixes and address ranges cannot overlap between separate pools.

In an address range, the low value must be a lower number than the high value. When multiple address ranges and prefixes are configured, the prefixes are depleted first, followed by the address ranges.

When you specify a port for dynamic source NAT, address ranges are limited to a maximum of 65,000 addresses, for a total of (65,000 x 65,535) or 4,259,775,000 flows. A dynamic NAT pool with no address port translation supports up to 65,535 addresses. There is no limit on the pool size for static source NAT.

Preserve Range and Preserve Parity

You can configure your carrier-grade NAT (CGN) to preserve the range or parity of the packet source port when it allocates a source port for an outbound connection. You can configure the preserve parity and preserve range options under the NAT pool definition by including the preserve-range and preserve-parity configuration statements at the [edit services nat pool poolname port] hierarchy level.

Preserving range and preserving parity are supported on MX series routers with MS-DPCs and on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. Preserving range and preserving parity are supported on MX series routers with MS-MPCs and MS-MICs starting in Junos OS release 15.1R1.

  • Preserve range—RFC 4787, Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, defines two ranges: 0 through 1023, and 1024 through 65,535. When the preserve-range knob is configured and the incoming port falls into one of these ranges, CGN allocates a port from that range only. However, if there is no available port in the range, the port allocation request fails and that session is not created. The failure is reflected on counters and system logging, but no Internet Control Message Protocol (ICMP) message is generated. If this knob is not configured, allocation is based on the configured port range without regard to the port range that contains the incoming port. The exception is some application-level gateways (ALGs), such as hello, that have special zones.

  • Preserve parity—When the preserve-parity knob is configured, CGN allocates a port with the same even or odd parity as the incoming port. If the incoming port number is odd or even, the outgoing port number should correspondingly be odd or even. If a port number of the desired parity is not available, the port allocation request fails, the session is not created, and the packet is dropped.

Specifying Destination and Source Prefixes Without Configuring a Pool

You can directly specify the destination or source prefix used in NAT without configuring a pool.

To configure the information, include the rule statement at the [edit services nat] hierarchy level:

Network Address Translation Rules Overview

To configure a NAT rule, include the rule rule-name statement at the [edit services nat] hierarchy level:

Each rule must include a match-direction statement that specifies the direction in which the match is applied.

Note:

ACX Series routers support only input as the match direction.

In addition, each NAT rule consists of a set of terms, similar to a firewall filter. A term consists of the following:

  • from statement—Specifies the match conditions and applications that are included and excluded.

  • then statement—Specifies the actions and action modifiers to be performed by the router software.

The following sections explain how the components of NAT rules:

Configuring Match Direction for NAT Rules

Each rule must include a match-direction statement that specifies the direction in which the match is applied. To configure where the match is applied, include the match-direction statement at the [edit services nat rule rule-name] hierarchy level:

The match direction is used with respect to the traffic flow through the Multiservices DPC and Multiservices PICs. When a packet is sent to the PIC, direction information is carried along with it. The packet direction is determined based on the following criteria:

  • With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

  • With a next-hop service set, packet direction is determined by the interface used to route the packet to the Multiservices DPC or Multiservices PIC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC or DPC, the packet direction is output. For more information about inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

  • On the Multiservices DPC and Multiservices PIC, a flow lookup is performed. If no flow is found, rule processing is performed. All rules in the service set are considered. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that matches the packet direction are considered.

Configuring Match Conditions in NAT Rules

To configure NAT match conditions, include the from statement at the [edit services nat rule rule-name term term-name] hierarchy level:

To configure traditional NAT, you can use the destination address, a range of destination addresses, the source address, or a range of source addresses as a match condition, in the same way that you would configure a firewall filter; for more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Alternatively, you can specify a list of source or destination prefixes by including the prefix-list statement at the [edit policy-options] hierarchy level and then including either the destination-prefix-list or source-prefix-list statement in the NAT rule. For an example, see Examples: Configuring Stateful Firewall Rules.

If the translation-type statement in the then statement of the NAT rule is set to stateful-nat-64, the range specified by the destination-address-range or the destination-prefix-list in the from statement must be within the range specified by the destination-prefix statement in the then statement.

If at least one NAT term within a NAT rule has the address pooling paired (APP) functionality enabled (by including the address-pooling statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level, all the other terms in the NAT rule that use the same NAT address pool as the address pool for the term with APP enabled must have APP enabled. Otherwise, if you add a NAT rule term without enabling APP to a rule that contains other terms with APP enabled, all the terms with APP enabled in a NAT rule drop traffic flows that match the specified criteria in the NAT rule.

For MX Series routers with MS-MICs and MS-MPCs, although the address pooling paired (APP) functionality is enabled within a NAT rule (by including the address-pooling statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level), it is a characteristic of a NAT pool. Such a NAT pool for which APP is enabled cannot be shared with NAT rules that do not have APP configured.

When configuring NAT, if any traffic is destined for the following addresses and does not match a NAT flow or NAT rule, the traffic is dropped:

  • Addresses specified in the from destination-address statement when you are using destination translation

  • Addresses specified in the source NAT pool when you are using source translation

Configuring Actions in NAT Rules

To configure NAT actions, include the then statement at the [edit services nat rule rule-name term term-name] hierarchy level:

  • The no-translation statement allows you to specify addresses that you want excluded from NAT.

    The no-translation statement is supported on MX series routers with MS-DPCs and on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. The no-translation statement is supported on MX series routers with MS-MPCs and MS-MICs starting in Junos OS release 15.1R1.

  • The system log statement enables you to record an alert in the system logging facility.

  • The destination-pool, destination-prefix, source-pool, and source-prefix statements specify addressing information that you define by including the pool statement at the [edit services nat] hierarchy level; for more information, see Configuring Pools of Addresses and Ports for Network Address Translation Overview.

  • The translation-type statement specifies the type of NAT used for source or destination traffic. The options are basic-nat-pt, basic-nat44, basic-nat66, dnat-44, dynamic-nat44, napt-44, napt-66, napt-pt, stateful-nat464, stateful-nat64, twice-basic-nat-44, twice-dynamic-nat-44, and twice-napt-44.

Note:

In Junos OS Release 13.2 and earlier, the following restriction was not enforced by the CLI: if the translation-type statement in the then statement of a NAT rule was set to stateful-nat-64, the range specified by the destination-address-range or the destination-prefix-list in the from statement needed to be within the range specified by the destination-prefix statement in the then statement. Starting in Junos OS Release 13.3R1, this restriction is enforced.

Configuring Translation Types

The implementation details of the nine options of the translation-type statement are as follows:

  • basic-nat44—This option implements the static translation of source IP addresses without port mapping. You must configure the from source-address statement in the match condition for the rule. The size of the address range specified in the statement must be the same as or smaller than the source pool. You must specify either a source pool or a destination prefix. The referenced pool can contain multiple addresses but you cannot specify ports for translation.

    Note:

    In an interface service set, all packets destined for the source address specified in the match condition are automatically routed to the services PIC, even if no service set is associated with the interface.

    Note:

    Prior to Junos OS Release 11.4R3, you could only use a source NAT pool in a single service set. As of Junos OS Release 11.4R3 and subsequent releases, you can reuse a source NAT pool in multiple service sets.

  • basic-nat66—This option implements the static translation of source IP addresses without port mapping in IPv6 networks. The configuration is similar to the basic-nat44 implementation, but with IPv6 addresses.

    The basic-nat66 option is not available if you are using MS-MPCs or MS-MICs.

  • basic-nat-pt—This option implements translation of addresses of IPv6 hosts, as they originate sessions to the IPv4 hosts in an external domain and vice versa. This option is always implemented with DNS ALG. You must define the source and destination pools of IPv4 addresses. You must configure one rule and define two terms. Configure the IPv6 addresses in the from statement in both term statements. In the then statement of the first term within the rule, reference both the source and destination pools and configure dns-alg-prefix. Configure the source prefix in the then statement of the second term within the same rule.

    The basic-nat-pt option is not available if you are using MS-MPCs or MS-MICs.

  • deterministic-napt44—This option implements algorithm-based allocation of blocks of destination ports and IP address. This ensures that an incoming (source) IP address and port always map to the same destination IP address and port, thus eliminating the need for the address translation logging. When you use deterministic-napt44, you must also use deterministic-port-block-allocation at the [edit services nat pool poolname port] hierarchy level.

    The deterministic-napt44 option is supported on MX series routers with MS-DPCs and on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. The deterministic-napt44 option if you are using MX Series routers with MS-MPCs or MS-MICs is supported only in Junos OS release 14.2R7 and later 14.2 releases and in release 15.1R3 and later 15.1 releases.

  • dnat-44—This option implements static translation of destination IP addresses without port mapping. The size of the pool address space must be greater than or equal to the destination address space. You must specify a name for the destination pool statement. The referenced pool can contain multiple addresses, ranges, or prefixes, as long as the number of NAT addresses in the pool is larger than the number of destination addresses in the from statement. You must include exactly one destination-address value at the [edit services nat rule rule-name term term-name from] hierarchy level; if it is a prefix, the size must be less than or equal to the pool prefix size. Any addresses in the pool that are not matched in the value remain unused, because a pool cannot be shared among multiple terms or rules.

  • dynamic-nat44—This option implements dynamic translation of source IP addresses without port mapping. You must specify a source-pool. The referenced pool must include an address configuration (for address-only translation).

    The dynamic-nat44 address-only option supports translating up to 16,777,216 addresses to a smaller size pool. The requests from the source address range are assigned to the addresses in the pool until the pool is used up, and any additional requests are rejected. A NAT address assigned to a host is used for all concurrent sessions from that host. The address is released to the pool only after all the sessions for that host expire. This feature enables the router to share a few public IP addresses between several private hosts. Because all the private hosts might not simultaneously create sessions, they can share a few public IP addresses.

  • napt-44—This option implements dynamic translation of source IP addresses with port mapping. You must specify a name for the source-pool statement. The referenced pool must include a port configuration. If the port is configured as automatic or a port range is specified, then it implies that Network Address Port Translation (NAPT) is used.

  • napt-66—This option implements dynamic address translation of source IP addresses with port mapping for IPv6 addresses. The configuration is similar to the napt-44 implementation, but with IPv6 addresses.

    The napt-66 option is not available if you are using MS-MPCs or MS-MICs.

  • napt-pt—This option implements dynamic address and port translation for source and static translation of destination IP address. You must specify a name for the source-pool statement. The referenced pool must include a port configuration (for NAPT). Additionally, you must configure two rules, one for the DNS traffic and the other for the rest of the traffic. The rule meant for the DNS traffic should be DNS ALG enabled and the dns-alg-prefix statement should be configured. Moreover, the prefix configured in the dns-alg-prefix statement must be used in the second rule to translate the destination IPv6 addresses to IPv4 addresses.

    The napt-pt option is not available if you are using MS-MPCs or MS-MICs.

  • stateful-nat464—This option implements 464XLAT Provider-Side Translater (PLAT) address translation for source IP addresses and IPv6 prefix removal translation for destination IPv4 addresses. You must specify the IPv4 addresses used for translation at the [edit services nat pool] hierarchy level. This pool must be referenced in the rule that translates the IPv6 addresses to IPv4.

    The stateful-nat464 option is available only if you are using MS-MPCs or MS-MICs, and is supported starting in Junos OS Release 17.1R1.

  • stateful-nat64—This option implements dynamic address and port translation for source IP addresses and prefix removal translation for destination IP addresses. You must specify the IPv4 addresses used for translation at the [edit services nat pool] hierarchy level. This pool must be referenced in the rule that translates the IPv6 addresses to IPv4.

  • twice-basic-nat-44—This option implements static source and static destination translation for IPv4 addresses, thus combining basic-nat44 for source and dnat-44 for destination addresses.

    The twice-basic-nat-44 option is supported on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices PICS. The twice-basic-nat-44 option is supported on MS-MPCs and MS-MICs starting in Junos OS Release 15.1R1.

  • twice-dynamic-nat-44—This option implements source dynamic and destination static translation for IPv4 addresses, combining dynamic-nat44 for source and dnat-44 for destination addresses.

    The twice-dynamic-nat-44 option is supported on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices PICS. The twice-dynamic-nat-44 option is supported on MS-MPCs and MS-MICs starting in Junos OS Release 15.1R1.

  • twice-napt-44—This option implements source NAPT and destination static translation for IPv4 addresses, combining napt-44 for source and dnat-44 for destination addresses.

    The twice-napt-44 option is supported on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices PICS. The twice-napt-44 option is supported on MS-MPCs and MS-MICs starting in Junos OS Release 15.1R1.

For more information on NAT methods, see RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.

Configuring NAT Rules for IPsec Passthrough for Non-NAT-T Peers

Before Junos OS Release 17.4R1, Network Address Translation-Traversal (NAT-T) is not supported for the Junos VPN Site Secure suite of IPsec features on the MX Series routers. Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, you can pass IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec peers that are not NAT-T compliant. Only ESP tunnel mode is supported. This feature is supported only on MS-MPCs and MS-MICs.

To configure NAT rules for IPsec passthrough for NAPT-44 or NAT64:

  1. Configure an IKE ALG application. See Configuring Application Properties.

  2. Add the application to an application set. See Configuring Application Sets.

  3. Configure a NAT pool. See Configuring Pools of Addresses and Ports for Network Address Translation Overview.

  4. Configure the NAT rule:

    1. Configure a match direction for the rule. See Configuring Match Direction for NAT Rules.

    2. Configure one of the matching conditions to be the application set for IKE and IPsec passthrough that you configured in Step 2.

    3. Configure other match conditions. See Configuring Match Conditions in NAT Rules.

    4. Configure the translation type as NAPT-44 or NAT64.

    5. Configure other NAT actions. See Configuring Actions in NAT Rules.

  5. Assign the NAT rule to a service set.

See Also

Protecting CGN Devices Against Denial of Service (DOS) Attacks

You can now choose configuration options that help prevent or minimize the effect of attempted denial of service (DOS) attacks.

Mapping Refresh Behavior

Prior to the implementation of the new options for configuring NAT mapping refresh behavior, described in this topic, a conversation was kept alive when either inbound or outbound flows were active. This remains the default behavior. You can now also specify mapping refresh for only inbound flows or only outbound flows. To configure mapping refresh behavior, include the mapping-refresh (inbound | outbound | inbound-outbound) statement at the [edit services nat rule rule-name term term-name then translated secure-nat-mapping] hierarchy level.

EIF Inbound Flow Limit

Previously. the number of inbound connections on an EIF mapping was limited only by the maximum flows allowed on the system. You can now configure the number of inbound flows allowed for an EIF. To limit the number of inbound connections on an EIF mapping, include the eif-flow-limit number-of-flows statement at the [edit services nat rule rule-name term term-name then translated secure-nat-mapping] hierarchy level.

Carrier-Grade NAT Implementation: Best Practices

The following topics present the best practices for carrier-grade NAT implementation:

Use Round-Robin Address-Allocation When Using APP with the MS-DPC

Best Practice:

If you are using an MS-DPC and you configure address-pooling paired (APP) in a NAT rule, you should use round-robin address allocation for the NAT pool.

The APP feature maps a private IP address to the same public IP address in a NAT pool for all the NAT sessions for that private IP address.

Sequential address allocation for NAT pools is the default on the MS-DPC, and allocates all the ports for a public IP address before assigning the next IP address. Sequential allocation, together with APP, might result in mapping multiple private hosts to the same public IP address, resulting in fast port exhaustion for a public IP address while other ports are still available from the remaining IP addresses in the NAT pool.

Round-robin allocation, on the other hand, assigns the next IP address in the NAT pool to the next private IP address needing translation, reducing the chance that all the ports for one public IP address are depleted.

For more information about APP and round-robin address allocation, see Configuring Address Pools for Network Address Port Translation (NAPT) Overview.

Note:

The MS-MPC and MS-MIC only use round-robin allocation.

The following example shows round-robin address allocation.

Use the EIM Feature Only When Needed

Best Practice:

Do not use endpoint-independent mapping (EIM) in NAT rule terms that include Junos ALGs. EIM assigns the same external NAT address and port for a specific session from a private host, but adds processing overhead. EIM provides no benefit for any of the Junos ALGs, which already employ the functionality used by EIM.

Best Practice:

Enable EIM for applications that do reuse the source ports and rely on a CGNAT device to maintain the same address and port mapping for all traffic sent to different destinations. For example, use EIM for console gaming applications such as Xbox and PS4 or applications that use unilateral self-address fixing methods (UNSAF). See (IETF RFC 3424 IAB Considerations for Unilateral Self-Address Fixing (UNSAF) Across Network Address Translation).

For more information about EIM, see Configuring Address Pools for Network Address Port Translation (NAPT) Overview.

The following example uses the Junos SIP ALG in the NAT rule, so EIM is not used.

Define Port Block Allocation Block Sizes Based on Expected Number of User Sessions

Best Practice:

For secure port block allocation and deterministic port block allocation, define a port block allocation block size that is 2 to 4 times larger than the expected average number of active sessions for a user. For example, if the user is expected to have an average of approximately 200 to 250 NAT sessions active, configuring the block size to 512 or 1024 provides a liberal allocation.

Best Practice:

If you are rolling out secure port block allocation using the MX Series as a NAT device and are not sure of your subscriber user profile and traffic profile, set the port block size to 1024 if you have enough NAT IP addresses to handle the estimated peak number of private subscribers. The number of NAT IP addresses times 62 gives you the number of private subscribers that can be handled with a port block size of 1024 (there are 62 blocks per IP address). Then, closely monitor the MX Series router by using the show services nat pool detail command to determine whether the block size needs to be changed.

Best Practice:

Be careful not to make the block size too large if the number of IP addresses you can allocate to the NAT pool is limited. Making a port block size that is large enough to efficiently assign the blocks to your subscribers might cause all the port blocks to be tied up.

Secure port block allocation allocates blocks of ports to a particular user for NAT44 or NAT64. Secure port block allocation limits the number of syslog messages by generating only one syslog per block of ports.

However, configuring the block size incorrectly can lead to inefficient use of NAT resources or to performance issues. For example, when a user connects to a website that requires the establishment of a significant number of sockets for a single HTML page, a corresponding number of new ports must be allocated. The port block size should be large enough to prevent continual allocation of new blocks. If the number of concurrent sessions for a private subscriber exceeds the number of ports available in the active port block, the other port blocks allocated to the subscriber are scanned for available ports to use or a new block is allocated from the free block pool for the subscriber. The scanning of allocated port blocks and allocation of additional blocks can result in delays in setting up new sessions and loading web pages.

For more information about port block allocation, see Configuring Secured Port Block Allocation and Configuring Deterministic NAPT.

The following example sets the port block size to 1024.

Considerations When Changing Port Block Allocation Configuration on Running Systems

Best Practice:

Before changing the secure port block allocation or deterministic port block configuration on a running system when using an MS-MPC or MS-MIC, plan for a quick disruption in the NAT sessions. The change in configuration results in the re-creation of all the current NAT sessions.

Best Practice:

Before changing the port block allocation configuration on a running system when using an MS-DPC, plan for a disruption of services. After changing the configuration, you must reboot the MS-DPC, or if this is not possible, you must deactivate and reactivate the service set.

Changes to port block allocation configuration include:

  • Changing any NAT pool PBA configuration.

  • Changing a PBA NAT pool to a non-PBA NAT pool.

  • Changing a non-PBA NAT pool to a PBA NAT pool.

For more information about configuring port block allocation, see Configuring Secured Port Block Allocation and Configuring Deterministic NAPT.

Do Not Allocate NAT Pools That Are Larger Than Needed

MS-MPC and MS-MIC

Best Practice:

When using NAPT44 as your translation type with the MS-MIC or MS-MPC, do not configure NAT pools that are larger than needed for the peak session rate, which would tie up valuable IPv4 resources. Each conversation, also known as a session, includes two flows — an ingress and egress flow. Each conversation requires one port and each IP address in the pool has a 1024-65535 port range (64K), so the NAT pool size does not need to be larger than:

peak number of conversations /64K

Best Practice:

When using NAPT44 as your translation type with the MS-MIC, we recommend a maximum NAT pool size of 128 addresses (a /25 network).

Best Practice:

When using NAPT44 as your translation type with the MS-MPC, we recommend a maximum NAT pool size of 256 addresses (a /24 network).

The maximum recommended NAT pool size when using NAPT-44 for an MS-MIC is 128 IP addresses because the MS-MIC supports a maximum of 14 million flows, or 7 million conversations, which require 7 million ports. A total of 7 million ports are available with 128 IP addresses, with each IP address having a port range of 1024-65535.

The maximum recommended NAT pool size for each slot on an MS-MPC when using NAPT-44 is 256 IP addresses because each slot supports a maximum of 30 million flows, or 15 million conversations, which require 15 million ports. A total of 15 million ports are available with 256 IP addresses, with each IP address having a port range of 1024-65535.

You can use larger pools than the recommended values, and you can expect that configurations that use the port block allocation (PBA) feature require larger pools. This is because PBA assigns blocks of ports to private IP addresses, which changes the pool efficiency model.

For more information about configuring NAT pools, see Configuring Pools of Addresses and Ports for Network Address Translation Overview.

MS-DPC

Best Practice:

When using NAPT44 as your translation type with the MS-DPC, do not configure NAT pools that are larger than needed for the peak flow rate, which would tie up valuable IPv4 resources. Each conversation includes two flows (1 reverse flow for each forward flow). Each conversation requires one port and each IP address in the pool has a 1024-65535 port range (64K), so the NAT pool size does not need to be larger than:

peak number of conversations /64K

Best Practice:

When using NAPT44 as your translation type with the MS-DPC, do not configure NAT pools with more than 64 addresses (a /26 network).

The maximum NAT pool size for an MS-DPC is 64 IP addresses because the MS-DPC supports a maximum of 8 million flows, or 4 million conversations, which requires a maximum of 4 million ports. A total of 4 million ports are available with 64 IP addresses, with each IP address having a port range of 1024-65535. If APP, EIM, and EIF are enabled, the MS-DPC supports a maximum of 5.8 million flows, or 2.9 million conversations, so the maximum NAT pool size would be less.

For more information about configuring NAT pools, see Configuring Pools of Addresses and Ports for Network Address Translation Overview.

Configure System Logging for NAT Only When Needed

Best Practice:

Do not enable system logging per session for secure port block allocation configurations.

Best Practice:

Do not enable system logging for deterministic NAT configurations.

Best Practice:

Enable system logging at the service-set level rather than at the services interface level when possible.

Best Practice:

In production networks, always send the log messages to an external system log server. This avoids adding CPU load to the Routing Engine, which occurs when messages are logged locally.

Best Practice:

Specify the system log class to restrict logging to the class of applications in which you are interested.

Best Practice:

If you configure system logging within a NAT rule term, use a stateful firewall rule to restrict the traffic that reaches the NAT rule term.

System log messages can negatively affect the performance of the services card, depending on the frequency of creation and deletion of sessions. All system log messages created by the services card require CPU processing at the services card, and the system log messages themselves constitute traffic that is sent across the MX Series router and competes with user traffic to reach the external log server.

Secure port block allocation removes the need to configure logs per session, because you know the block and block size and can derive the ports allocated to each user.

Deterministic NAT removes the need to log at all, because all information on port allocation can be deduced mathematically.

The following example restricts logging to NAT events and sends log messages to the external log server 203.0.113.4

When you configure system logging within a NAT rule term, all traffic that enters the NAT rule term generates a log, which can cause excessive logging. This might result in the logging rate limit being reached, and you would lose logs that you do need.

For more information about configuring system logging for NAT, see Configuring NAT Session Logs.

Limit the Impact of Missing IP Fragments

Best Practice:

For the services interface that is configured for NAT, limit the impact of missing or delayed fragments by configuring the following:

  • Maximum number of fragments for a packet

  • Maximum wait time for a missing fragment

IP fragments received by the services card configured for NAT are buffered as they arrive. This allows an integrity check of the completely reassembled packet before the packet is processed by NAT. Missing or delayed fragments can cause the already received fragments to be held until the internal buffer is full and they are flushed out, resulting in CPU usage overhead and reduced traffic forwarding.

Configuring the maximum number of fragments a packet can have and limiting the wait time for a missing fragment reduces the chance of the internal buffer becoming full.

The following example sets the maximum number of fragments to 10 and the maximum wait time to 3 seconds.

Do Not Use Configurations Prone to Packet Routing Loops

Best Practice:

Prevent packet routing loops by ensuring that only the intended traffic is allowed to reach the services card and be processed by the service set NAT rule. You can do this by:

  • Configuring a source-address range under the NAT rule when possible.

  • Configuring a firewall filter that accepts only the traffic meant to be serviced by the NAT rule in a next-hop style service set.

Packet looping between the Packet Forwarding Engine and the services card results in persistent high CPU usage on the services card. Packet looping can be caused by the services card receiving traffic from an unexpected private source network. When unexpected traffic is processed by NAT, a pinhole is created, and in the case of EIF many pinholes might be created. These pinholes cause routing loops if the return traffic routes back through the services card.

The following example shows a firewall filter that only allows traffic from 198.51.100.0/24 to reach services interface ms-1/0/0, which is the inside interface for a next-hop service set.

For more information about configuring firewall filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

The following example shows a NAT rule that only processes traffic from 198.51.100.0/24 (other traffic reaches the services interface, but is not processed).

For more information about configuring NAT rules, see Network Address Translation Rules Overview.

Inactivity Timeouts

Best Practice:

Set the inactivity timeout only for user-defined applications that could require the NAT session mapping to remain in memory for longer than the default NAT inactivity timeout of 30 seconds. For example, an HTTP or HTTPS banking application may require more than 30 seconds of inactivity because the user must enter data.

Best Practice:

Before making changes to the existing inactivity timeouts, run the following commands several times during peak hours. Then run the commands after making the changes, and verify that the changes are not starving the MX Series router of NAT resources or the services card of memory.

The following example shows the inactivity timeout being set to 1800 seconds for HTTPS and HTTP applications.

For more information about configuring user-defined applications, see Configuring Application Properties.

You need to weigh the risks of setting high inactivity timeouts for all traffic. While the default NAT inactivity timeout of 30 seconds may be too low for some user-defined applications, setting a timeout value too high can tie up NAT resources. For example, setting high inactivity timeout values can tie up any TCP session that is inactive just minutes after it was created. If the TCP session is not cleanly closed by a FIN or RST by the client or server, the session will sit in memory and tie up the NAT resources assigned to it until the timeout value expires.

Setting higher inactivity timeouts that impact every UDP and TCP port can be dangerous, especially with UDP traffic like DNS. Unlike TCP, UDP has no way to end a session other than timing out, so all UDP sessions would stay active for the full inactivity timeout value.

The following example is not a recommended configuration because it sets high inactivity timeout values for all TCP and UDP traffic.

We do not have specific recommended inactivity timeout values. The proper inactivity timeout values depend on several factors, including:

  • What applications are used on an end user’s network

    For example, Apple has stated that an inactivity timeout of 60 minutes is required for the following Apple services, which require a long connection lifetime:

    • Apple Push Services: inbound TCP port 5223

    • Exchange Active Sync: inbound TCP port 443

    • MobileMe: inbound TCP ports 5222 and 5223

  • How the NAT solution is being used, for example as a Gi NAT device or as an Enterprise edge router

  • How large your NAT pools are

  • How much traffic each services card receives during peak loads

  • How much memory you have available

Enable Dump on Flow Control

Best Practice:

Enable the dump-on-flow-control option for any services card that is processing NAT traffic in a production network. This option detects when a services card is locked up, writes a core dump that Juniper Networks can analyze to determine why the card locked up, and recovers the services card by restarting it.

For the MS-MIC and MS-MPC, set the dump-on-flow-control option under the pc- interface, which is used to send control traffic from the Routing Engine to the services card. The following example shows the configuration if the services interface is ms-2/1/0.

For the MS-DPC, set the dump-on-flow control option under the sp- interface. The following example shows the configuration if the services interface is sp-2/1/0.

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.1R1
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, you can pass IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec peers that are not NAT-T compliant.
16.1
Starting in Junos OS Release 16.1, the limit-ports-per-address statement is supported.
14.2
Starting in Junos OS Release 14.2, configure the NAT pool as follows.