Converting from Dataplane NAT to VPF NAT

VPF offers significant advantages over the NAT features in the dataplane. Not only is it more stable, but if offers features and flexibility not possible with dataplane NAT.

Dataplane NAT will be deprecated, but currently there is no automatic conversion from dataplane NAT to VPF NAT. Both methods are available in this release.

Manually converting from dataplane NAT to VPF NAT requires a few key steps to ensure the transition goes smoothly.

Note

NAT configurations vary significantly between deployments so this document does not contain comprehensive before/after NAT examples. Use the information as a guide for how to adjust each specific configuration rather than commands to be used as-is.

Warning

Connections will be disrupted during this process, schedule an appropriate maintenance window with sufficient time for testing.

See also

Before starting, review the VPF NAT Behavior Notes.

The general process is:

Take a Backup

Before proceeding, take a backup of the current configuration as described in Configuration Backups.

Warning

Do not skip this step. If there is a problem with the conversion, restoring the backup can return TNSR to a working state.

Another good practice is to create a manual entry in the Configuration History in addition to the backup:

tnsr(config)# configuration history version save vpf-nat-before

Configure VPF NAT

Next, create a set of VPF NAT rules equivalent to the current dataplane NAT configuration. Configuring VPF while it is disabled does not disrupt the current NAT behavior, so the rules and other settings can be configured before attempting the changeover.

See also

The VPF section of the documentation contains numerous VPF NAT Examples.

NAT Pool Addresses

For TNSR to utilize addresses with VPF NAT, traffic for the NAT addresses must be delivered to TNSR from upstream.

With VPF, there is no global option to set NAT pools. The NAT addresses are configured directly on NAT rules. They can be hard-coded in rules as prefixes, configured as interface addresses, or defined by VPF tables (VPF Tables).

See also

For a list of all the ways traffic can be translated, see Network Address Translation Operations.

However, TNSR will not automatically respond to ARP and ICMP echo requests (ping) for addresses used in VPF NAT rules. Before they can function properly, addresses configured in NAT rules must be either routed to TNSR from upstream or configured on TNSR interfaces (Configure Interfaces).

Note

This is different than dataplane NAT, which automatically responds to ARP requests for addresses in NAT pools.

If the NAT rules only use existing interface addresses or addresses in prefixes routed to TNSR, there is nothing to do for this step.

Outbound NAT

VPF uses rulesets on interfaces to define what happens on ingress and egress. This is different from dataplane NAT, which uses configuration flags for inside/outside on interfaces to determine how to perform outbound NAT.

Dataplane NAT automatically performs NAT for subnets on inside interfaces as traffic egresses via outside interfaces. VPF requires matching subnets explicitly, either in NAT rules directly or by using tables. VPF can also match much more narrowly and only perform NAT for specific sources or destinations (Source and Destination Address Matching), specific protocols (Protocol Options), and based on other matching criteria. See VPF NAT Rules for details.

The small example NAT rule below is from the Zero-to-Ping NAT Section, which performs source NAT and port translation for the 172.16.1.0/24 subnet as the traffic exits the WAN interface, using the IP address on the WAN interface as the translated source.

tnsr(config)# vpf nat ruleset WAN-nat
tnsr(config-vpf-nat-ruleset)# description NAT for WAN
tnsr(config-vpf-nat-ruleset)# rule 1000
tnsr(config-vpf-nat-rule)# description NAT from LAN prefix
tnsr(config-vpf-nat-rule)# direction out
tnsr(config-vpf-nat-rule)# dynamic
tnsr(config-vpf-nat-rule)# algorithm ip-hash
tnsr(config-vpf-nat-rule)# from ipv4-prefix 172.16.1.0/24
tnsr(config-vpf-nat-rule)# nat-interface WAN
tnsr(config-vpf-nat-rule)# exit
tnsr(config-vpf-nat-ruleset)# exit
tnsr(config)#

Tip

VPF NAT is also much more capable than dataplane NAT in terms of how it performs NAT. It can NAT to different addresses based on sources, such as using different external addresses for different internal interfaces (Outbound NAT/NAPT with Separate Addresses for Internal Networks) and it can also use different algorithms to determine how internal addresses are mapped to different external addresses (Network Address Translation Operations).

See also

Static NAT

The type of NAT actions called “Static NAT” in dataplane NAT are all handled by NAT rule configurations in VPF.

Each of these must be converted separately by adding appropriate rules to NAT rulesets.

For details, see VPF NAT Rules and the following examples:

Disable and Remove Dataplane NAT

Once the VPF rulesets are complete, the next task is to disable dataplane NAT and remove its configuration.

Warning

This will disrupt traffic through TNSR which requires NAT to function.

Connectivity will be restored once VPF is enabled.

First, remove the NAT inside/outside configuration from every interface. In this example, the WAN was configured as an outside interface while LAN was an inside interface.

tnsr(config)# int WAN
tnsr(config-interface)# no ip nat
tnsr(config-interface)# exit
tnsr(config)# int LAN
tnsr(config-interface)# no ip nat
tnsr(config-interface)# exit

Note

Check every interface for ip nat statements. For example, in addition to internal interfaces such as LANs, it is common for VPN interfaces to be configured as inside NAT interfaces.

Remove all nat static mapping statements (port forwards, 1:1 NAT, twice NAT):

tnsr(config)# no nat static mapping

Remove the NAT pool configuration. The exact command will vary based on the current configuration, but in general it is possible to remove everything by using the following two commands:

tnsr(config)# no nat pool addresses
tnsr(config)# no nat pool interface

Now disable dataplane NAT:

tnsr(config)# no nat global-options nat44 enabled

Enable VPF

The last part of configuring VPF requires associating rulesets with interfaces. In most cases this will only involve adding a ruleset to an external-facing interface such as a WAN:

tnsr(config)# vpf options
tnsr(config-vpf-option)# interface WAN nat-ruleset WAN-nat
tnsr(config-vpf-option)# exit

Finally, enable VPF itself:

tnsr(config)# vpf enable

With dataplane NAT disabled and VPF NAT enabled, the configuration conversion is complete. Traffic should be flowing again with VPF performing the NAT.

Test VPF NAT

With VPF NAT active, test every type of NAT configured in VPF to ensure that it is translating all connections properly.

This includes outbound connections as well as any other types of NAT such as port forwards, 1:1 NAT, and so on.

If NAT is not functioning as expected, review and adjust the rules to achieve the desired results. Most cases are resolved by ensuring the correct traffic is matched. If necessary, disable VPF and re-enable dataplane NAT.

Take Another Backup

With a working configuration in place, the best practice is to take another backup of the configuration (Configuration Backups).

After taking a backup, add another manual entry in the configuration history:

tnsr(config)# configuration history version save vpf-nat-after