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 AS or MultiServices PIC. When a packet is sent to the
PIC, direction information is carried along with it.
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 AS 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, the packet direction is output. For more information
on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.
On the AS or 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 NAT Type for Terms in NAT Rules
The NAT type specifies whether a particular term supports traditional
NAT processing or full-cone NAT. A full-cone NAT
is one in which all requests from the same internal IP address and
port are mapped to the same external IP address and port. In addition,
any external host can send a packet to the internal host by sending
it to the mapped external address. Full-cone NAT is useful if you
want to allow external hosts from the public network to connect to
internal hosts using public IP addresses. However, we recommend that
you use this feature along with strict firewall rules that allow only
the intended traffic from the public network to reach the customer-edge
router.
To configure the NAT type, include the nat-type statement
at the [edit services nat rule rule-name term term-name] hierarchy level:
full-cone—Specifies that the term supports
full-cone NAT.
symmetric—Specifies that the term supports
only traditional NAT; this is the default setting.
The following specifications and restrictions apply to full-cone
NAT:
As long as an internal host has a connection to an external
host and uses source NAT, this feature allows any external host to
connect back to the internal host over the public IP network.
When the internal host terminates its connection to the
external host, initiation of any new connections from external host
to internal host over the public IP network is disallowed. Existing
connections are not affected.
Use of full-cone NAT enables the external-to-internal
host connection to be independent from the internal-to-external host
connection with regard to protocol and source and destination port.
The aging mechanism for the external-to-internal host
connection is similar to other host connections. Once the connection
is established from the external host to the internal host, it is
treated like any other network connection.
Full-cone NAT is available with both source static and
source dynamic NAT processing; for more information, see Configuring Actions in NAT Rules.
It supports IPv4 addresses on Juniper Networks J-series
Services Routers only. It is not supported on M-series or T-series
routing platforms.
It does not support Port Address Translation (PAT) or
Network Address Port Translation (NAPT).
It is not supported for use with twice NAT configurations.
To configure traditional NAT and twice 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 JUNOS Policy Framework Configuration 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.
You can include application protocol definitions that you have
configured at the [edit applications] hierarchy level; for
more information, see Applications Configuration Guidelines:
To apply one or more specific application protocol definitions,
include the applications statement at the [edit services
nat rule rule-name term term-name from] hierarchy level.
To apply one or more sets of application protocol definitions
that you have defined, include the application-sets statement
at the [edit services nat rule rule-name term term-name from] hierarchy level.
Note:
If you include one of the statements that specifies application
protocols, the router derives port and protocol information from the
corresponding configuration at the [edit applications] hierarchy
level; you cannot specify these properties as match conditions.
You can configure ALGs for ICMP and trace route under stateful
firewall, NAT, or class of service (CoS) rules when twice NAT is configured
in the same service set. Twice NAT does not support any other ALGs.
By default, the twice NAT feature can affect IP, TCP, and UDP
headers embedded in the payload of ICMP error messages. You can include
the protocol tcp and protocol udp statements with
the application statement for twice NAT configurations.
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 to be excluded from NAT.
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 Addresses and Ports for Use in NAT Rules.
The overload-pool and overload-prefix statements
specify a pool of addresses or an address prefix that can be used
if the source pool becomes exhausted. If all the addresses in the
source pool are in use, additional NAT sessions are supported using
the overload pool. The overload pool must have NAPT configured.
For twice NAT, you can apply an overload pool for source addresses
and combined source and destination addresses.
The syslog statement enables you to record an alert
in the system logging facility.
The translation-type statement specifies what type
of network address translation is used for source or destination traffic:
destination static—Implement address translation
for destination traffic without port mapping. This requires the size
of the source address space to be the same or smaller than the size
of the destination address space. You must specify a destination-pool name. The referenced pool can contain multiple addresses but no port configuration.
source dynamic—Implement address translation
for source traffic with NAPT. You must specify a source-pool name. The referenced pool must include a port or address configuration.
If port automatic or port range is specified, port translation
is used. If a port is not defined, the port value defaults to 1.
The source dynamic option supports translating a large
range of 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. Since all the private
hosts might not simultaneously create sessions, they can share a few
public IP addresses.
source static—Implement address translation
for source traffic without port mapping. The size of the pool address
space must be greater than or equal to the source address space. You
must specify a source-pool name. The referenced pool must
contain exactly one address or prefix and no port configuration.
You must include exactly one source-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 source-address value
remain unused, because a pool cannot be shared among multiple terms
or rules.
For traditional NAT, you can configure either translation-type
destination or translation-type source, but not both.
To configure twice NAT, you specify both a translation-type destination and a translation-type source.
Note:
You can statically assign NAT addresses from a dynamic NAT pool.
This capability enables you to advertise one subnet that represents
the NAT pool and use an address within that subnet for static rules.
Statically assigned addresses are not reused for dynamic assignment.
Statically assigned addresses from a dynamic pool can only be used
for source static NAT and not for destination static NAT.
Note:
When configuring NAT, if you specify the following addresses
that do not match the NAT flow or NAT rule, the corresponding 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
For more information on NAT methods, see RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.
