"Twice NAT" with NSX-T T0 Gateway

 

Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule (similar to this guy) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon. 

While working with NSX-T and listening to customer problems, I've encountered many circumstances in the datacenter that required a twice NAT sort of solution. For years I was unaware that NSX routers contained a twice NAT equivalent, until last month. How could I overlook this? You'll notice in the NSX UI that there is no option for twice NAT. So how do you get this twice NAT to work?


Check out my YouTube video where I talk about this and explain how to implement "twice NAT". I put it in quotes because the method you'll see requires two NAT rules, not one. Performing two NATs with one rule is the hallmark of twice NAT, but you'll see that the way I configure it achieves the same outcome. 



Thanks goes out to a colleague, Vivek,  who helped in the discovery process. The discovery was stumbled upon in response to a customer who was having trouble providing access to an application in their datacenter. The solution required that I step back from this special type of NAT, twice NAT, and understand how NSX-T processes packets at the interface. You'll see in the below diagrams that a Tier-0 gateway performs DNAT on the packet during interface ingress and SNAT on the packet at egress. To arrive at the net effect of twice NAT, it takes two NAT rules. What this experience taught me is the value of taking a first principles approach to problem solving.  By some cognitive bias that I can't name, I could only see that twice NAT was the solution here rather than using a DNAT and SNAT independently to achieve the same outcome.  



Lets look at the diagram I used as the bases for the YouTube lab. Again, this was based on an actual customer problem (the specifics have been changed). You can see a more detailed description of the problem by clicking the image. The customer configured a DNAT rule sending traffic to the web server, which works fine for users outside of the NSX domain. However, for other applications and users inside the NSX domain, the DNAT rule wasn't cutting it. The details require knowledge that a Tier 0 gateway has both an SR VRF and DR VRF, with SR being the only VRF capable of NAT. Rather than detail it here, I think it makes more sense to watch the video to see a live example.   


Ultimately, bidirectional network traffic is achieved by configuring the following NAT rules. This forces all of the traffic to pass through the Tier 0 gateway's SR VRF, which is the only VRF doing NAT.


Armed with this information, you should have no problem identifying a circumstance requiring twice NAT and applying the proper solution! Happy routing!

Comments

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Packet Capture Network Traffic Inside ESXi Hypervisor