vBond advertising wrong public IP of vManage

[kubn2]

Hello,

I have a lab with 3 sites.

Site ID 1 is the main one, vbond, vmanage, and vsmart all of them has 10.X IP range assigned fro VPN 0 interface and it's then statically NATed to public IP.

Site ID 100 has vEdge with a public IP assigned to interface in VPN 0 and here vbond correctly providing private IP and public IP of vmanage and vsmart.

Site ID 200 has vEdge with private IP (192.168.X) which is then NATed (PAT) in ISP network. On this site I have an issue, I can establish connection to vBond and I can reach public IPs of vmanage and vsmart but vBond instead of providing public IP of vmanage (like on the site 100) it's providing private ip 10.X as a public one. 

Do you have any idea how I can fix vBond and force him to provide public IP of vManage for this site?

[Kanan Huseynli]

Hi,

let me guess the issue.

You have controllers with the private IP address (here, there is no problem), but you didn't do NAT hairpinning for controller to vBond traffic, so vBond knows only private address of vManage.

Could you share this output:

from vmanage:

show run system

show control connections | inc vbond

from vbond:

show orchestrator connections | inc vmanage|vsmart

[kubn2]

Hi Kanan,
Well that's not true, vBond knows public IP of the vManage because like I mentioned, it's providing public IP of the vManage to the site 100 where vEdge has public IP assigned to VPN 0, meanwhile on site 200 where VPN 0 has a private IP assigned vBond provide only private IP of the vManage.

[Kanan Huseynli]

Understood your point.

Could you share before asked information? Also, this problematic vEdge configuration (are you sure for site-id?)

Also share show control connections - from working vedge.

Did you set carrier in any tunnel configuration?

[kubn2]

So here are the control connections from working vEdge on site 100

And I'm attaching requested output from your previous message. I didn't set the carrier command in any tunnel, I tried it now but the issue is still the same

[Ahmed Sheibani]

Hi Kanan,

I have same problem

[Kanan Huseynli · Accepted solution]

You have the scenario exactly what I described. You didn't do NA hairpinning for controller-to-controller traffic.

You vBond does not aware vSmart/vManage public IP address. Because traffic to vBond comes from private vSmart/vManage IP address.

How does it work with pure public IP on vEdge?

The reason is controller initiates traffic to vEdge. vEdge public IP (IP) is reported to controller and when controller initiates to vEdge it works normal and since it passes controller NAT device, vEdge sees vSmart/vManage with public IP.

How doesn't it work with PAT IP on vEdge?

The reason is controller initiates traffic to vEdge. vEdge public IP is reported to controller and when controller initiates to vEdge it does not work, because PAT does not accept outside initiated traffic. In addition, vEdge tries to access controller which also does not work, because there is no route to private IP address (vEdge knows only private IP of controller).

In "cisco-sd-wan-overlay-network-bringup" something like this is described:

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/cisco-sd-wan-overlay-network-bringup.html

The solution is proper design of controllers with NAT. vBond must know public IP of vSmart and vManage. For this, you should do NAT hairpinning on NAT devices (works great with firewall, especially if vBond and vSmart/vManage are in different DMZ zones). Also, in configuration you should set vBond public IP under system (not private as in your vSmart/vManage configuration).

You can search for "BRKENT-2296" and ""BRKRST-2559" in Ciscolive on-demand session for detailed design. https://www.ciscolive.com/on-demand/on-demand-library.html

SD-WAN CVD also describes on-prem controller design, but in short paragraph ,definitely recommend Ciscolive sessions:

On-Premise Controller Deployment