1:1 NAT¶
This example maps an internal address of 10.30.0.100 to an external address
of 203.0.113.230 without any port translation. This effectively maps all
ports between both addresses in both directions, so that the internal host can
make external connections which appear to originate from the external address as
well as accept connections inbound to that external address.
Note
This is a common requirement for servers running protocols which may not handle being behind NAT well, such as a PBX. It is also common with e-mail servers which require operating on separate external address for both inbound and outbound communication.
First, TNSR must know to handle traffic for the external address. This can be accomplished either by having the address be in a prefix routed to TNSR from upstream, or by configuring the external address on an interface directly. In this example, the address is part of the WAN subnet, so adding it to the WAN interface is appropriate:
tnsr(config)# interface WAN
tnsr(config-interface)# ip address 203.0.113.230/24
tnsr(config-interface)# exit
Next, add the VPF NAT rules. VPF requires a rule for each direction, so two rules are necessary to fully configure 1:1 NAT.
Create the inbound NAT rule using the external address as the destination and the internal address as the NAT prefix:
tnsr(config)# vpf nat ruleset WAN-nat
tnsr(config-vpf-nat-ruleset)# rule 50
tnsr(config-vpf-nat-rule)# description 1:1 NAT Inbound
tnsr(config-vpf-nat-rule)# direction in
tnsr(config-vpf-nat-rule)# algorithm one-to-one
tnsr(config-vpf-nat-rule)# to ipv4-prefix 203.0.113.230/32
tnsr(config-vpf-nat-rule)# nat-prefix 10.30.0.100/32
tnsr(config-vpf-nat-rule)# exit
Create the outbound NAT rule using the internal address as the source and the
external address as the NAT prefix. As these rules are a pair and work together,
it’s safe to only increase the sequence number by 1:
tnsr(config-vpf-nat-ruleset)# rule 51
tnsr(config-vpf-nat-rule)# description 1:1 NAT Outbound
tnsr(config-vpf-nat-rule)# direction out
tnsr(config-vpf-nat-rule)# algorithm one-to-one
tnsr(config-vpf-nat-rule)# from ipv4-prefix 10.30.0.100/32
tnsr(config-vpf-nat-rule)# nat-prefix 203.0.113.230/32
tnsr(config-vpf-nat-rule)# exit
tnsr(config-vpf-nat-ruleset)# exit
Note
These rules could also have both dynamic and no-port-translation
set, but it is unnecessary for 1:1 NAT to be configured in that way. Those
keywords are only required when VPF must keep a NAT translation state, which
is not necessary with static 1:1 NAT, since VPF already knows exactly how to
translate traffic in both directions based solely on the configuration.
Finally, add VPF filter rules to pass traffic in and out. Outbound traffic may already be covered by existing outbound rules. Inbound traffic should be restricted to only services which must be exposed to untrusted sources.
For example, rules may need to include:
Allow specific service connections inbound on WAN from any source to the external address on the required ports.
Allow connections outbound on WAN from the internal host to any destination.
Allow connections inbound on LAN from the internal host to any destination.
Allow connections outbound on LAN to the internal host from any source, optionally restricted to specific services, but this is typically unnecessary as restricting on the external interface is typically sufficient.