Twice-NAPT (Or Dual NAT or some times referred as Hairpin NAT) is usually used in a setup where a traffic from Lan which is destined to a public Destination-IP is redirected back to same LAN after a destination-NAT.
In general, DNAT configuration is used for inbound traffic from internet, to translate a public destination IP address with server’s private IP address. It maybe associated with a specific service/port (eg. Web/RDP/TCP-8080 etc.).
However, when an internal machine try to access this domain, it doesn’t work and we need twice-napt configuration for it to work.
Lets see what happens when client PC from same Lan try access this server without a Twice-NAT configuration. Here is a brief flow of packet. (If you understand the flow, you may skip to configuration section).
Considerations:
Client PC – 192.168.1.25
Server domain – myserver.domain which resolves to 100.1.1.10
Server IP – 192.168.1.10
Service – RDP (tcp-3389)
Client PC generates a packet with source-IP 192.168.1.25 and destined to 100.1.1.10.
Versa receives this packet at Lan interface, Lan-VR will route packet towards WAN-VR (due to the default or specific route, through the split-tunnel tvi).
In Wan-VR due to DNAT configuration, destination IP (100.1.1.10) will be changed to Server’s private IP (192.168.1.10) and now next-hop will be towards Lan.
Wan will forward the packet towards Lan-VR
Lan-VR will forward the packet towards to Server in Lan.
If a NAPT (Source Network Address Port translation) is configured for internet going traffic, it will not trigger, since it would be done at the packet egress through the WAN. So, the source will remain same as Client’s private IP (192.168.1.25). At the time packet will leave Versa Lan interface it will have following details
Source-IP: 192.168.1.25; Destination-IP: 192.168.1.10;
Now, if this packet will hit Server in Lan, Server will see source-IP (192.168.1.25) as its own Lan subnet and so it will reply directly to Client PC.
When this packet will be received by Client PC, it will discard, as it was expecting response from the requested external IP (100.1.1.10) and not from an internal IP (192.168.1.10).
To get this flow working we need to implement Twice-NAT, source-(port)-Nat along with Destination-Nat. When this traffic is routed back by Wan-VR towards Lan, we need to change source address to something that Server return packet back to Versa. This source address can be a tvi/loopback interface IP in Lan-VR or Lan interface (GW) itself.
Configuring Twice-NAT (Hairpin NAT)
1.a. Define a pool for Destination NAT
1.b. Define Server’s actual (private) IP.
1.c. Define service-port for which you need DNAT to work
2.a. Now define a pool for source-nat (for looped flow).
2.b. Define LAN as network, or Lan interface IP, to Source (port) NAT with it.
A loopback/another tvi interface for NAPT can be defined, so return traffic from Server is forward back to Versa.
2.c. Configure automatic port assignement.
3. Now we have DNAT and NAPT defined, we need to configure a policy to to do cgnat.
3.a. Configure a cgnat rule
3.b. Configure match criteria
3.b. Configure action, defining both twice-napt-44 and both source and destination pools.
Additional Checks:
- Ensure that your next-hop in Lan-VR for the Serve’s public subnet is pointing towards right Wan-VR.
- If twice-nat rule is conflicting with default napt (source nat) configuration or not being preferred due to any other rule, increase the precedence of rule twice-nat in step 3.a. (all rules has default precedence 1).
- In step 3.b. defining source-zone, or source Lan subnet will prevent a conflict with dedicated DNAT pool, if defined for external (ingress) traffic.