what is Network address translation traversal?

[knaik99]

Vbond is responsible for Network address translation traversal so what is meaning of that and how it works/

[Naseer Anjan]

vBond is the first point of contact for your Edge devices, vSmart. So, vBond should aware of your Public IP and Private IP incase you have hosted your SDWAN components behind NAT. Hence, vBond able to provide vManage's both IPs to your Edge routers and Edge router will form control connections with vManage, vSmart using anyone of the IP or both IP (if reachable via underlay network). 

Moreover, if deploying all controllers inside your DC, and make them available on both public and private network, you need to consider dedicated zone to be provisioned for vBond alone since vBond has to be communicated with NAT IP (public IP) by other Controllers such as vManage, vSamrt. 

[Adrian Jimenez]

If you still need help… NAT Traversal on SDWAN is simply the way to know if a vEdge is behind NAT or not. The vBond works as a STUN server (Session Traversal Utilities for NAT), when the vEdge starts up it attempts to connect to the vBond and at that point it sends a STUN request which has the original IP of the TLOC it’s connecting from (i.e 192.168.123.100). Say that request goes through a Firewall NAT and src ip is changed to (209.165.201.1). Once this gets to the vBond, it will compare the actual source IP against the STUN information and know that the vEdge is behind NAT simply because IPs are different. The vBond sends a STUN response which tells the vEdge something like “hey you’re behind NAT in case you don’t know”. 

Now that the vEdge knows it’s behind NAT, here’s why the whole process it’s important…the vEdge can now advertise its TLOC route to vSmart and include what its public IP is. vSmart then advertises that to other vEdges and that’s how other vEdges will know to what public IP to target their data plane tunnels. Makes sense? I wish I could make a diagram but replying from my phone, I had this same question at some point and took me a while to figure it out. Hope this helps and any question let me know! 

[nagrajk1969]

hi

this logical explanation does makes sense...

But it raises some additional queries...

Vedge1---(firewal/router)nat----internet---vedge2

- If vedge2 (after it gets to know the public ip of edge1 thru vsmart) were to "initiate" the tunnel to vedge1 public ip 209.165.201.1....wouldnt it be necessary that there should be a DNAT/Static1:1Nat rule on the Firewall/router (translating to 192.168.123.100)?

- Or would it be that the tunnel MUST be initiated from vedge1 ONLY...to any other vedgeX?....

- AND since this vedge1(and some more in this network domain) being behind a NAT-router would this be deployment work ONLY in a hub-spoke fixed topology with each of the vedgeX communicating via hub ONLY?....if yes it has to be in hub-spoke, then what kind of router/gateway is the hub?

- And is there any specific udp-port encapsulation used for these NAT-T tunnel packets?.....just like udp-4500 for ipsec nat-t tunnels?

[Adrian Jimenez]

Ahhh...this is a great follow up question!

This is actually why the vBond has to reside on a public space. When vEdge1 attempted connection to the vBond, it opened the control connection to it on 192.168.123.100:12346 (part of the base ports pool for control connections). If the FW is actually doing Dynamic NAT, it will create the translation and have the table updated at that point. Say it translates it to 209.165.201.1:12346, the FW will keep the same base port for the sake of argument. The TLOC route vEdge1 sends to the vSmart has both private/public IP and port. You can check this on a "show omp tlocs detail".

When vEdge2 goes through the bringup process, it will send its own TLOC routes and receive the vEdge1 TLOC route from vSmart. vEdge2 will know what IP and port to connect to. And viceversa, vEdge1 will have the TLOC route from vEdge2. Any can initiate the connection at that point. So having to reach the vBond on a public space creates translation entry which is then used when other vEdges target sessions with that destination.

Now, about the hub-and-spoke question...the whole process of connecting to controllers before doing anything does look like a hub-and-spoke scenario in the sense of vEdge have to reach vBond first, to then get vSmart information to connect to it and then get TLOCs received/advertised. But it really doesn't have to do with anything related to how the data plane topology will look like. Let's add a vEdge3 into the equation, it goes through the same process described above...it will then get TLOC routes from vEdge1 and vEdge2. At that point all 3 vEdges will have BFD sessions (or data plane tunnels or IPSec tunnels however you want to call it) between each other building up a mesh topology (which is by default the data topology SDWAN has if not restricting TLOC connections, etc). What I'm trying to say is that how NAT-T works doesn't influence the data plane topology. 

And lastly, in the Cisco SDWAN solution world STUN messages are sent through the control connection attempted to the vBond so this will get carried on the default DTLS ports control connections use (12346, 12366, 12386,12406,12426).