SD-WAN Controller hosted On-prem || How vBond know NATed public IP

[Sushil93]

Hello Team,

Please help me to understand: in hybrid scenario of Controller deployment, if vBond resides behind the NAT, and lets say cEdge on-boarding is done with the Internet as TLOC then as we know, vBond should learn both the Private and NATed public IP addresses on it interface

--> So, In this case w hat will be the configuration on the vBond, vSmart and vManage , so that vBond learn the NATed IP address of vSmart & vManage on its interface.

Topology is attached for your reference.

Thanks in Advance !!

[Torbjørn]

Assuming that vBond is correctly set up with a public IP(either directly, or with 1:1 NAT), it will be able to get the private and public IP of cedges behind NAT using STUN. The cedge will tell the vBond its private IP in the stun packet, and the vBond is able to see the public IP on the received IP header.

You can read more about STUN here: https://en.m.wikipedia.org/wiki/STUN

[Sushil93]

@Torbjørn: Thanks for your response but the raised query is bit different, it is : what will be the configuration on the vBond, vSmart and vManage , so that vBond learn the NATed IP address of vSmart & vManage on its interface.

I understand the STUN functionality which is used by cEdge during onboarding if the vBond resides behind NAT and cEdge is onboarding with the Internet TLOC.

Thanks in Advance !!

[Torbjørn]

Sorry @Sushil93, I misinterpreted your question.

The controllers also use STUN to inform vBond of public & private addresses. As for configuration, all that is needed is for the "vbond {ip or fqdn}" command to be configured under the system configuration. The controllers will then register with the vBond(and inform of addresses using STUN) such that it can direct cEdges to them.

[Sushil93]

@Torbjørn: Thanks for your reply !! i understand it means : on controllers : vManage & vSmart the NATed public IP is configured under system along with vBond as stun server.

Please add if i missed something !!

[Torbjørn]

That is correct, on the vManage and vSmart you would configure the NATed public IP of the vBond as such:

system
 vbond {vBond address/FQDN}

[Kanan Huseynli]

Hi

what is the deployment type? If on-prem and all controllers are behind nat, then you need nat hairpinning. Better design is to put vsmart and vmanage in the same firewall zone, vbond in different zone and do proper NATs.

Check below topic, I have shared lots of related resources.

https://community.cisco.com/t5/sd-wan-and-cloud-networking/on-prem-controllers-deployment-vbond-sits-in-dmz-with-nat-1-1/td-p/4260104

[Sushil93]

@Kanan Huseynli: Thanks for your response !!

what is the deployment type?: this is hybrid depolyment --> Controllers are in Public cloud in VPC under the same subnet or same firewall zone as well as rendundant controllers are there in another region in the VPC having same subnet.

I need more understanding on the point mentioned by you :

"Better design is to put vsmart and vmanage in the same firewall zone, vbond in different zone and do proper NATs"

As in our scenario all the controller are behind the NAT and in same subnet VPC in the same firewall zone --> so, what are the complications will be there if the they are in the same firewall zone and reachable under same subnet ?

---> As better design, what are the complexities i can avoid by putting vBond in different DMZ ?

i want to connect with you on this to discuss further for our scenario if you have some time to discuss.

Thanks in Advance !!

Regards

[Torbjørn]

The controllers need to reach vBond in such a way that they will inform the vBond of the same public and private IP addresses as the WAN edges will "see". WAN edges will not be able to reach the controllers the vBond doesn't know the correct public and private addresses for the control-plane components.

This can either be solved by doing NAT hairpinning(allowing "inside" devices to reach other "inside" devices by their public IP addresses) or by moving the vBond to a different network, such that regular NAT can be used.

If vSmart and vManage can currently reach vBond on it's public IP address this shouldn't be an issue.

[Sushil93]

Thanks Torbjorn For you suggestion and guidance.

Its "U" turn on the Firewall which resolves the communication of vBond over Public IP addresses with other controllers.

[Kanan Huseynli]

Is firewall gateway for all controllers? Will do you 1:1 NAT (so allocated one separate IP per controller)

Below NAT is typical for intra-zone or inter-zone NAT hairpinning:

source: vsmart_private ; destination: vbond_public  <translate> source: vsmart_public ; destination: vbond_private
source: vmanage_private ; destination: vbond_public  <translate> source: vmanage_public ; destination: vbond_private

source: vsmart_private ; destination: any <translate> source: vsmart_public; destination: any
source: vmanage_private ; destination: any <translate> source: vmanage_public; destination: any
source: vbond_private ; destination: any <translate> source: vbond_public; destination: any

In last three NATs destination can be also object-group which contains all remote controllers and routers.

[Sushil93]

Thanks Kanan For you suggestion and guidance.

Its "U" turn on the Firewall which resolves the communication of vBond over Public IP addresses.