Converting from Dataplane NAT to VPF NAT

Dataplane NAT has been removed from TNSR. Environments which require NAT must use VPF NAT. VPF offers significant advantages over the NAT features formerly available in the dataplane. Not only is VPF NAT more stable, but it offers features and flexibility that were not possible with dataplane NAT.

There is no automatic conversion from dataplane NAT to VPF NAT, rulesets must be converted manually. The upgrade process removes dataplane NAT from the TNSR configuration, which will disrupt any traffic which relies upon NAT.

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# db history version save vpf-nat-before

Configure VPF NAT

Next, create a set of VPF NAT rules equivalent to the previous dataplane NAT configuration.

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 from dataplane NAT, which automatically responded 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 used configuration flags for inside/outside on interfaces to determine how to perform outbound NAT.

Dataplane NAT automatically performed 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 which were 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 VPF NAT rulesets.

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

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 VPF NAT enabled, the configuration conversion is complete. Traffic should be flowing 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.

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# db history version save vpf-nat-after