I've been there.
You've got an SD-WAN edge device behind NAT and you just can't get it to join the control-plane fabric, or even worse: It's joined to the control plane and vSmart, but some or all of it's BFD tunnels are down.
In our brave new world where google search results consist entirely of SEO Garbage or AI slop, you'll likely be misled into believing the Vbond-as-stun-server command, allow-service stun may allow your edge router to traverse the treacherous NAT path.
You might get even more confident once you see the thousands of incorrect posts on the cisco supportforums erroneously claiming that by default vBond uses STUN to determine if a device is behind NAT. This is completely incorrect.
Before you use this command and instantly regret typing out "commit", it's worth taking a quick look at the Cisco SD-WAN cEdge CLI command reference:
Command: Vbond-as-stun-server
To enable Session Traversal Utilities for NAT (STUN) and allow the tunnel interface to discover its public IP address and port number when the Cisco IOS XE SD-WAN device is located behind a NAT, use the vbond-as-stun-server command in tunnel interface configuration mode. When you configure this command, Cisco IOS XE SD-WAN devices can exchange their public IP addresses and port numbers over private TLOCs. To disable STUN, use the no form of the command.
Command Default:
STUN is not enabled by default.
Sounds great right? Silly Cisco! Why would you not enable this by default? it's so useful!
The usage guidelines tell a different story,
With this configuration, the Cisco IOS XE SD-WAN device uses the Cisco vBond orchestrator as a STUN server, so that the device can determine its public IP address and public port number. The device cannot learn the type of NAT that it is behind. No overlay network control traffic is sent and no keys are exchanged over tunnel interface configured to use the Cisco vBond orchestrator as a STUN server. However, BFD does come up on the tunnel, and data traffic can be sent on it.
As you can probably understand from the bolded text, this command is not very likely to help you with getting your control plane traffic to work over NAT since it disables control traffic over interfaces configured with this command!
The logic here is that the Edge router already has a way of determining its public IP and private IP, that's what the vBond is for!
When an Edge router connects to the hostname* you have specified for the vBond, in the DTLS exchange it will provide it's "real" (Private IP Address) and source Port to the vBond.
If the Edge router is behind a NAT device, the vBond will be able to determine this by looking at the source ip and source port of the DTLS packet as compared to the "real" (Private IP) and source port the Edge router asserts in the DTLS exchange
So, as you can see, the "stun" protocol is not needed by vBond here, it's got it's own way of determining if your device is behind NAT.
In conclusion, it's very unlikely the "vbond-as-stun-server" command is going to help you, in fact it's very likely to cause you just completely lose connection to your Edge router since, as stated in the CLI reference:
"No overlay network control traffic is sent and no keys are exchanged over tunnel interface configured to use the Cisco vBond orchestrator as a STUN server."
It's worth noting the CLI reference points out that BFD tunnels will still be established over any interface configured with this command. Hey Cisco, can't I accomplish that just by using control-preference commands? This command to me at least, seems like a solution looking for a problem.
Then again, I could be wrong dear reader! If you've had a reason to use this command, please comment and let me know i'd be interested to learn more.
Happy NAT-Traversal everyone!
*As per my previous blog post, It's not best practice or good design to use an IP address when configuring the system vbond command because the hostname can be configured to return two IP addresses in the DNS response, Your Edge router needs to be able to talk to at least two separate vBond's in order to correctly determine what "type" of NAT gateway you are behind (Address Independent or Port independent)
