The NAT options described here control TNSR NAT behavior independent of interfaces and address pools.
When Endpoint-dependent NAT mode is active, it will affect traffic to and from services on TNSR, such as IPsec and BGP. When NAT is enabled in this mode, by default TNSR will drop traffic that doesn’t match an existing NAT session or static NAT rule. To change this behavior, enable NAT forwarding mode:
tnsr(config)# nat global-options nat44 forwarding true
If Endpoint-dependent NAT is active and there are no services present on TNSR which need to communicate using an interface involved with NAT, then it is more secure and efficient to disable forwarding:
tnsr(config)# nat global-options nat44 forwarding false
NAT Session Timeout Duration¶
nat global-options timeouts (icmp|tcp_established|tcp_transitory|udp)
<seconds> command controls how long NAT sessions in various states will be
retained while idle (no packets passing which match the session entry).
Longer session idle timeouts are friendlier to user connections, at the expense of resource consumption required to retain the NAT sessions for long periods.
The following timeout values can be changed:
Idle timeout for ICMP sessions (e.g. Echo/ping). The default value is
Idle timeout for established TCP connections. Established connections should rarely be forced down in most use cases, so a long timeout is best for this value. The default value is
7440seconds (2 hours, 4 minutes). It is common to see this set as high as
86400(24 hours) in deployments with long-lived idle connections.
Idle timeout for TCP connections which are not fully established (being setup or torn down). The default value is
240seconds (4 minutes) which is typically sufficient.
Idle timeout for UDP sessions. Since UDP is technically stateless and has no formal setup/tear-down for sessions, there is no way for TNSR to determine if a UDP “connection” is established or finished. The default value is
300seconds (5 minutes) which, combined with client and server keep-alives, is typically sufficient.
A longer idle timeout may be required in certain cases, such as for VoIP connections passing through which expect to reuse specific source ports.
In deployments with many short-lived UDP connections, such as DNS queries, lowering the timeout will help manage session usage/turnover more efficiently.
show nat config command output includes the current timeout values.