Introduction
Twice NAT (Network Address Translation) is a technique where NAT is applied to both – source and destination IP addresses of the IP packet as it transits through the router. This article provides an overview of Twice NAT use cases, configuration and verification on Versa VOS using Versa Director. Screenshots and configuration examples in this article are made in Versa Director and VOS 22.1.4, however the same approach is applicable for 21.2 versions as well (with some GUI differences).Twice NAT – Use Cases
There are following main use cases for using Twice NAT:1. Interconnecting different Networks, which use Private IP space. Example: there can be two organizations – OrgA and OrgB, each using IP addresses from Private (RFC1918) IP Space in their networks, and they’ve established interconnection so that users from OrgA (“Source_IP_A” on diagram) could use certain services hosted inside OrgB network (“Destination_IP_B” on diagram). In this case OrgA can allocate IP range from its internal IP space (“Destination_IP_A” on diagram) to address destination resources from OrgB, and OrgB can allocate IP range from its internal IP space to address OrgA users (“Source_IP_B” on diagram). Twice NAT will be applied on the VOS router on the edge of OrgA and OrgB networks, performing needed translations for source and destination IPs:
2. As an Element of Network Obfuscation technique, when IP addressing in one segment of the network needs to be “obfuscated” from another. This can be used to hide internal network structures or to apply additional IP-based segregation.
Example: Organization may not want to expose real IP addresses between its two different environments, even if they have non-overlapping IP addressing.
Twice NAT – Configuration steps
As an example in this section, it would be demonstrated how to configure Twice NAT between two networks which have overlapping IP Space:
The following steps would be used to configure Twice NAT on VOS using Versa Director (usually you may want to do this in Device Template or Service Template):
3.1 Pre-requisites
• Remember to allocate additional IP (or IP ranges):
o For Destination NAT in OrgA (will be used to translate OrgB IPs) o For Source NAT in OrgB (will be used to translate OrgA IPs)
• CGNAT service needs to be enabled on the VOS for the tenant, in which you configure it. If you don’t see CGNAT section in Configuration’s “Services” tab, then you may need to check following both places to confirm that CGNAT service is enabled:
o Configuration->Others->Service Nodes->Service Node Groups, and click on “default-sng”. If ‘cgnat’ service is not in ‘Selected Services’ list, then add it there:
o Configuration->Others->Organization->Limits and click on desired Tenant Name, then switch to ‘Services’ tab. If ‘cgnat’ service is not in ‘Services’ list, then add it there:
3.2 Source NAT (SNAT) Pool configuration
This Pool will be used to translate OrgA IPs inside OrgB:
1. Go to Configuration->Services->CGNAT->Pools, and click “+ Add”. On ‘General’ tab give it a name:
2. On ‘IP Address’ tab configure desired IP allocation for the pool – this can be either IP Range in IP/Mask notation or specifying low/high IPs, or Egress Network, or Egress Interface. In this example we will configure IP range for this pool. As per initial task statement, it’s expected that all source IPs of OrgA have to be translated into 10.100.0.1, so this pool will consist of this single IP (don’t forget to click “+” when after specifying the range):
Note that it’s also possible to parameterize IP range values, so they can be filled further in Bind data, which can be useful in case of using Service template, which then can be applied to different devices.
3. On ‘Port’ tab set Source Port Allocation Scheme as Automatic:
3.3 Destination NAT (DNAT) Pool configuration
This Pool will be used to translate OrgA destination IPs into real IPs from OrgB:
1. Go to Configuration->Services->CGNAT->Pools, and click “+ Add”. On ‘General’ tab give it a name:
2. On ‘IP Address’ tab configure desired IP allocation for the pool – in case of DNAT Pool only IP Range in IP/Mask notation or specifying low/high IPs is applicable. As per task statement, it’s expected that internal destination IP of OrgA has to be translated into 10.0.0.10 when sent to OrgB, so this pool will consist of this single IP (don’t forget to click “+” when after specifying the range):
Note that it’s also possible to parameterize IP range values, so they can be filled further in Bind data, which can be useful in case of using Service template, which then can be applied to different devices.
3. As per task statement, it’s expected that whole internal destination IP of OrgA has to be translated, so on ‘Port’ tab leave “Destination port” ranges unchecked, however if it’s needed to translate only certain destination port(s) of OrgA IP to certain destination port(s) of OrgB IP, those OrgB IP port(s) should be specified in this section:
Now both CGNAT pools are configured, however they are only “building blocks” to be used in CGNAT Rule, so this would be the next step of configuration.
3.4 CGNAT Rule configuration
CGNAT Rule is the main configuration element of CGNAT configuration, which defines what and how to translate. CGNAT Rule sequence in the list doesn’t matter, however rule processing order is defined by “Precedence” value configured in each rule (the higher – the more preferred).1. Go to Configuration->Services->CGNAT->Rules, and click “+ Add”. On ‘General’ tab give it a Name and Precedence (the higher – the more preferred):
Note regarding Precedence value: if device already has CGNAT rules for DIA, created by a workflow, it may also have default “RFC_1918_NoTranslate” CGNAT Rule, which will prevent translation if source and destination IPs are from RFC1918 space. In our scenario such rule should be overcome by Twice NAT, so the Precedence of Twice NAT Rule should be higher than 100.
2. “Match” tab defines which traffic should be translated, and it is split into 2 subtabs – “Source” and “Destination”. Both subtabs should match traffic as it’s seen on OrgA side: with source IPs from 10.0.0.0/24 range and destination IP 10.255.0.10:
And for Destination match:
3. Next, it’s needed to configure “Action” tab:
a. First of all “NAT mode” – for Twice NAT it can be one of:
i. Twice Basic NAT-44 —Translate the IPv4 source and destination addresses statically.
ii. Twice Dynamic NAT-44 —Translate the IPv4 source address by dynamically choosing the NAT address from the source address pool and translate the destination address statically.
iii. Twice NAPT-44 —Translate the transport identifier (that is, the source IP address) of an IPv4 private (OrgA) network to a single IPv4 external address (that is, OrgB source IP address) and translate the destination address statically.
As the task states that it’s needed to translate OrgA’s internal source range into the single OrgB’s IP (so SNAT range sizes are different), we select Twice NAPT-44 in this scenario.b. Then it will ask to provide Source and Destination Pools:
c. Optionally you may enable logging for this rule by specifying LEF Profile (or selecting “Default Profile” to send to Analytics), but be careful because CGNAT rules may produce big amounts of logs.
3.5 Note on Twice NAT prefix advertisements
In case there’s a Dynamic routing protocol running on Twice NAT router with its peers, you may need to take care additionally about advertising DST-IP prefix to OrgA and SNAT-pool prefix to OrgB – the same way as it would need to be done in case of separate Source or Destination NAT scenarios. A possible option for this is following:1. Create static routes for SNAT-pool and DST-IP ranges with “Discard” action set. Optionally you can assign Monitor to this static route.
2. Readvertise those static routes to Dynamic routing protocol, filtering OrgA’s DST-IP prefix from being advertised to OrgB, and OrgB’s SNAT-pool prefix – from being advertised to OrgA.
3.6 Note on NGFW Security rules with Twice NAT prefixes
If NGFW Security rules are configured on router with Twice NAT, you need to use real IP addresses for matching Twice NAT flows in Security rule. In this example, it would be source:10.0.0.0/24 (real Source IPs in OrgA) and destination:10.0.0.10 (real Destination IP in OrgB)4 Twice NAT – Verification
Twice NAT operation can be verified using following approach:1. Check counters for the corresponding CGNAT rule:
show orgs org-services <TENANT_NAME> cgnat rules <CGNAT_RULE_NAME>Example:
admin@Branch-cli> show orgs org-services Versa-Org cgnat rules Twice-NAT-Rule statistics
FORWARD FORWARD REVERSE REVERSE
HIT PKT BYTE PKT BYTE
COUNT COUNT COUNT COUNT COUNT
-------------------------------------------
2 5 420 5 420
Possible issues and troubleshooting scenarios:
• Hit count is not increasing:
o Verify that forward traffic is reaching VOS router (for example, DST-IP prefix is being properly advertised to OrgA – see p.3.5 of this article for details). session extensive information mentioned in this section can also confirm this or provide more details about what else can be happening.
o Verify that no other CGNAT rule with higher precedence is being hit instead of this one – this can be verified using session extensive data mentioned in this section. See also a note in p.3.4.1 of this article.
• Reverse packet count is not increasing for bi-directional connection:
o Verify that reverse traffic is reaching VOS router (for example, SNAT-pool prefix is being properly advertised to OrgB – see p.3.5 of this article for details). More troubleshooting information can be obtained with session extensive data mentioned in this section
2. Verify session extensive information for natted sessions:
With VOS it’s possible to get many details for each session using ‘show orgs org <TENANT_NAME> sessions extensive’ command. Below is the suggested adjustment for this command to provide its output in a convenient formatting for analyzing natted sessions:show orgs org <TENANT_NAME> sessions extensive | select natted Yes | select source-ip | select destination-ip | select nat-source-ip | select nat-destination-ip | select nat-source-port | select nat-destination-port | select nat-rule-name | select forward-pkt-count | select reverse-pkt-countIf there are a lot of natted sessions, it’s possible to add additional filtering criteria (one or several) in the end of above mentioned command, like:
| select source-ip A.B.C.D | select destination-ip E.F.G.H | select source-port X | select destination-port Y | match-allExample:
admin@Branch-cli> show orgs org Versa-Org sessions extensive | select natted Yes | select source-ip | select destination-ip | select nat-source-ip | select nat-destination-ip | select nat-source-port | select nat-destination-port | select nat-rule-name | select forward-pkt-count | select reverse-pkt-count
FORWARD REVERSE NAT NAT NAT
VSN VSN SESS DESTINATION PKT PKT NAT DESTINATION SOURCE DESTINATION
ID VID ID SOURCE IP IP COUNT COUNT SOURCE IP IP PORT PORT NAT RULE NAME
--------------------------------------------------------------------------------------------------------------------------
0 2 1904 10.0.0.100 10.255.0.10 8 10 10.100.0.1 10.0.0.10 53368 22 Twice-NAT-Rule
Possible issues and troubleshooting scenarios:
• No natted session is seen:
o Verify that forward traffic is reaching VOS router (for example, DST-IP prefix is being properly advertised to OrgA – see p.3.5 of this article for details). You may also try the same ‘show … session extensive’ command without “select natted Yes” filter – to confirm whether this traffic is not reaching the router at all or CGNAT is not happening. In case CGNAT is not happening you may need to verify created CGNAT policy and any other CGNAT policy with higher precedence, which may match this traffic (see also a note in p.3.4.1 of this article)
• Incorrect NAT source and/or destination IPs:
o Verify that “NAT RULE NAME” for the session matches the expected created CGNAT rule. Otherwise verify match criteria in a created CGNAT rule and its precedence (see p.3.4)
o Verify created CGNAT rule and pools assigned to it (see p.3.3 and 3.4)
• Reverse packet count is not increasing for the bi-directional connection:
o Verify that traffic is leaving VOS router: get full session extensive information ( show orgs org <TENANT_NAME> sessions extensive | select source-ip A.B.C.D | select destination-ip E.F.G.H | select source-port X | select destination-port Y | match-all ) and verify “forward-egress-ckt” and “access-policy”. If access-policy is not expected one, then verify match criteria taking into consideration note from p.3.6 of this article.
o Verify that reverse traffic is reaching VOS router (for example, SNAT-pool prefix is being properly advertised to OrgB – see p.3.5 of this article for details)
