cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13137
Views
0
Helpful
10
Replies

vManage, vBond and vSmart behind NAT

alxzed
Level 1
Level 1

Unfortunately I cannot find any documentation regarding this design. I am trying to install vManage and vBond in a DMZ with private 10.X.X.X address and do static NAT on the firewall facing Internet. This doesn't seem to be working for vManage. I can see my first ISR trying to connect to the private IP of vManage. Is it required for vManage, vBond and vSmart to have public Internet IP addresses?

This is what ISR shows for vBond and vManage:

 

Router#show sdwan control connection-history 

<<SKIP>>
vmanage dtls 10.0.253.1 1 0 10.0.254.1 12346 10.0.254.1 12346 default connect DCONFAIL NOERR 
vbond dtls - 0 0 209.XX.XX.XX 12346 209.XX.XX.XX 12346 default tear_down VB_TMO NOERR

2 Accepted Solutions

Accepted Solutions

No, you didn't get me. You don't need public addresses assigned to controllers, but controllers should interact with each over via public (NATed) addresses.

View solution in original post

one way to solve this is to put vbond on public ip in DMZ with 1:1 nat from outside and other controllers in inside zone, when the try accessing the public vbond ip they also get natted from inside to DMZ using public so vbond will look at both public and private ips. Also you need to configure port offset for one of the private controllers so that nat device can know the difference between connections.

View solution in original post

10 Replies 10

tahiali
Cisco Employee
Cisco Employee

vbond needs to be public or behind 1:1 nat, with no tunnel interface configured, rest all the controllers can be behind nat. (try avoiding symmetric nat)

vbond will help doing NAT traversal for natted devices

keep in mind to open the list of Firewall ports.

vedges can also be behhind nat but for those links you have to use public colors. 

 

https://sdwan-docs.cisco.com/Product_Documentation/Getting_Started/Viptela_Overlay_Network_Bringup/01Bringup_Sequence_of_Events/Firewall_Ports_for_Viptela_Deployments

 

Yeah, that's pretty much what I am doing. I played around with it today. I had tunnel interface on vBond which I removed but it didn't help the situation. From tcpdump on vManage it keeps sending packets to the ISR, but the ISR keeps sending ICMP UDP unreachable:

00:16:59.781515 IP 10.0.254.1.12346 > 173.XX.XX.XX.12366: UDP, length 16
00:16:59.851824 IP 173.XX.XX.XX > 10.0.254.1: ICMP 173.XX.XX.XX udp port 12366 unreachable, length 52

 

ISR keeps showing the same DCONFAIL LOCAL ERROR for vManage control connection. 

Firewall has all ports open on vBond, vManage and vSmart IPs. It is 1:1 NAT for all of them. They all sit in the same DMZ subnet in the same datacenter behind the same firewall. ISR is open Internet with public IP.

 

Is there a special config for NAT-T to be enabled on vBond or vEdges? It looks like that the problem is related to inability for vEdges to discover public IP of vManage/vSmart from vBond. 

ekhabaro
Cisco Employee
Cisco Employee

There is one important concept that should be always considered and remembered when using private addresses on controllers.
Control elements should use publically routable IP addresses for communication between them or in other case you'll see situation like you have:
Edge device will try to connect to private address because vBond itself communicate with other controllers via private addresses and does not know anything about their public addresses, hence can't communicate this information to Edge devices.

Well that is exactly what I originally asked :) Do I need public Internet IPs on VPN 0 interfaces or private with 1:1 NAT is ok to use.

So are you saying that I actually do need public IP on VPN 0 for each vManage, vBond and vSmarts that I have?

 

No, you didn't get me. You don't need public addresses assigned to controllers, but controllers should interact with each over via public (NATed) addresses.

i have met same problem and cant solve. please share me solution for this case, i stuck at here 1 week ago.

All our controllers are behind NAT.

 

How does it work if some cEdges need to communicate with Public IP of the controllers and some only need to talk to the private IP?

 

Currently, the vsmart and vmanage connections are built over the private network.  Over the public network, vbond connection is established, but vbond is giving out private IP of the controllers.  If I reconfigure the controllers to interact with each other via public IP, will it break the private network connection with no internet access to the controllers?

one way to solve this is to put vbond on public ip in DMZ with 1:1 nat from outside and other controllers in inside zone, when the try accessing the public vbond ip they also get natted from inside to DMZ using public so vbond will look at both public and private ips. Also you need to configure port offset for one of the private controllers so that nat device can know the difference between connections.

All our controllers are behind NAT.

 

How does it work if some cEdges need to communicate with Public IP of the controllers and some only need to talk to the private IP?

 

Currently, the vsmart and vmanage connections are built over the private network.  Over the public network, vbond connection is established, but vbond is giving out private IP of the controllers.  If I reconfigure the controllers to interact with each other via public IP, will it break the private network connection with no internet access to the controllers?

I ran into this problem when deploying the controllers in OpenStack. I had been configuring vManage and vSmart to use the private IP for vBond (since they were on the same subnet). When I re-configured them to use vBonds public (floating) IP, the traffic between the controllers would then hairpin the OpenStack router, allowing vBond to see the public (floating) IP of vManage and vSmart and advertise this address to the edge routers.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: