I’m reviewing SonicWall NSv for a hybrid cloud setup. The ISP provided a /29 and wants BGP. Their config looks standard, but the SonicWall won’t establish a neighbor session.
I’ve matched AS numbers, confirmed the peer IP, and set the local IP correctly. No filters applied yet. The logs just show repeated attempts and state changes to idle.
Before I waste another day on support, has anyone actually gotten BGP to work reliably on this platform? I’m checking if this is a known limitation with virtual appliances or if there’s a specific gotcha in the BGP template that isn’t documented.
The ISP insists their side is fine. I’m skeptical.
read the fine print
Yeah, the NSv BGP implementation can be a bit particular. I've seen it work, but only after checking a few easy-to-miss items.
Double-check the virtual interface settings in your hypervisor. The NSv sometimes drops BGP packets if the vNIC isn't in promiscuous mode, or if there's an MTU mismatch between the virtual switch and the SonicWall interface. Also, verify the route to the ISP peer IP is actually pointing out the correct interface in the SonicWall routing table - it might be trying to use a default route via another path.
Their support will probably ask for a tech support file. Capture that first, it'll save time.
I've validated BGP on NSv 6.5.4 in a lab, but it required a specific sequence the UI doesn't enforce. After you input the neighbor details, you must commit, but then immediately navigate to the BGP Advanced page and enable "Enable BGP" there as a separate checkbox. The main page toggle isn't sufficient.
Also, confirm the TCP source port behavior. In my test, the NSv was sourcing connections from an ephemeral port, but the ISP router was configured to expect TCP 179 from our side as well. We had to add a specific outbound NAT policy on the NSv to force the BGP session to originate from port 179. The session transitioned from idle to established immediately after.
If those don't apply, enable BGP debug logging via the CLI (`debug bgp all`) and look for a TCP negotiation failure. That will tell you if the three-way handshake is even completing.
That's an excellent find about the TCP source port. It's a classic example of an operational assumption, where the ISP config expects the standard BGP port on both ends, that isn't met by the appliance's default ephemeral behavior. This has tripped me up with other vendors' firewalls in the past, though usually it's the other way around, where the firewall blocks the ISP's source port.
Your point about the separate "Enable BGP" checkbox is also critical. It speaks to a UI/UX inconsistency I often see in vendor platforms, where a major function toggle is buried in an advanced submenu, completely separate from the primary configuration page. It creates a checklist item for my deployment playbook: after committing the neighbor, always verify the global enable flag in the advanced section.
I'd add that if the NAT policy fix works, you'll want to lock it down to only the ISP peer IP and port 179 to avoid unintended side effects.
null