Firewall Port Considerations for Cisco SDWAN

• The secure sessions between the WAN Edge routers and the controllers (and between controllers), by default are DTLS, which is User Datagram Protocol (UDP)-based.
• The default base source port is 12346.
• The WAN Edge may use port hopping where the devices try different source ports when trying to establish connections to each other in case the connection attempt on the first port fails.
• The WAN Edge will increment the port by 20 and try ports 12366, 12386, 12406, and 12426 before returning to 12346.
• Port hopping is configured by default on a WAN Edge router, but you can disable it globally or on a per-tunnel-interface basis.
• It is recommended to run port-hopping at the branches but disable this feature on SD-WAN routers in the data center, regional hub, or any place where aggregate traffic exists because connections can be disrupted if port hopping occurs.
• Note that port hopping is disabled on the controllers by default and should be kept disabled.
• Control connections on vManage and the vSmart controller with multiple cores have a different base port for each core.
• For WAN Edge routers that sit behind the same NAT device and share a public IP address, you do not want each WAN Edge to attempt to connect to the same controller using the same port number. Although NAT or port hopping may allow both devices to use a unique source port, you can instead configure an offset to the base port number of 12346, so the port attempts will be unique (and more deterministic) among the WAN Edge routers.
• A port offset of 1 will cause the WAN Edge to use the base port of 12347, and then port-hop with ports 12367, 12387, 12407, and 12427. Port offsets need to be explicitly configured, and by default, the port offset is 0.

Alternatively, you can use TLS to connect to the vManage and vSmart controllers, which is TCP-based instead of UDP-based. vBond controller connections always use DTLS, however. TCP ports originate on the WAN Edge from a random port number, and control connections to controllers with multiple cores have a different base port for each core, like the DTLS case.

Examples of DTLS and TLS control connections are shown in the following diagram.

• Note that every core on vManage and vSmart makes a permanent connection to vBond while WAN Edge routers makes a transient connection to vBond, using DTLS only.
• The WAN Edge routers connect to only one vManage and vSmart core. vManage and WAN Edge routers act as clients when connecting to vSmart controllers, so when using TLS, their source ports are random TCP ports > 1024.
• The WAN Edge router in the TLS example is configured with an offset of 2, so it uses the offset on the DTLS source port when connecting to vBond.

• IPsec tunnel encapsulation from a WAN Edge router to another WAN Edge router uses UDP with similar ports as defined by DTLS.
• Ensure that any firewalls in the network allow communication between WAN Edge routers and controllers and between controllers. Ensure that they are configured to allow return traffic as well.

Additional Ports for the VPN 0 Transport

In VPN 0 on the transport interface, almost all communication occurs over DTLS/TLS or IPsec, but there are a few other ports that need consideration.

Network Configuration Protocol (NETCONF)

The NETCONF protocol defines a mechanism through which network devices are managed and configured. vManage uses NETCONF for communication with SD-WAN devices, primarily over DTLS/TLS, but there are a few situations where NETCONF is used natively before DTLS/TLS connections are formed:

• When any controller (vManage, vBond, or vSmart) is added to vManage, a vManage instance uses NETCONF to retrieve information from them and allows them to be added as devices into the GUI. This might be when initially adding controllers to vManage, or for incremental horizontal scaling deployments, by adding vManage instances to a cluster or adding additional vSmart or vBond controllers.
• If any controller reloads or crashes, then that controller uses NETCONF to communicate back to vManage before encrypted DTLS/TLS sessions are re-formed.
• NETCONF is also used from vManage when generating Certificate Signing Requests from controllers through the vManage GUI before DTLS/TLS connections are formed.

NETCONF is encrypted SSH using AES-256-GCM and uses TCP destination port 830.

Secure Shell (SSH)

• SSH provides a secure, encrypted channel over an unsecured network.
• It’s typically used to log into a remote machine to execute commands, but it can also be used in file transfer (SFTP) and secure copy (SCP) from and to all SD-WAN devices.
• vManage uses SCP to install signed certificates onto the controllers if DTLS/TLS connections are not yet formed between them.
• SSH uses TCP destination port 22.

Network Time Protocol (NTP)

• NTP is a protocol used for clock synchronization between network devices.
• If an NTP server is being used and can natively be accessed through the VPN 0 WAN transport be sure NTP is allowed through the firewall.
• NTP uses UDP port 123.

Domain Name System (DNS)

• DNS may be needed if you are using a DNS server to resolve hostnames and the server is reachable natively through the VPN 0 transport.
• You may need DNS to resolve the vBond or NTP server name.
• DNS uses UDP port 53.

Hypertext Transfer Protocol Secure (HTTPS) (vManage)

• HTTPS provides an admin user or operator secure access to vManage, which can be accessed through the VPN 0 interface.
• vManage can be accessed using TCP port 443 or 8443.

Summary of additional VPN 0 protocols for SD-WAN device communication

Service	Protocol/Port	Direction
NETCONF	TCP 830	bidirectional
SSH	TCP 22	bidirectional
NTP	UDP 123	Outgoing
DNS	UDP 53	Outgoing
HTTPS	TCP 443/8443	bidirectional

Protocols Allowed Through the Tunnel Interface

Note that the VPN 0 transport interface is configured with a tunnel so control and data plane traffic can be encrypted, and native traffic can be restricted. 
Other than DTLS or TLS, the following native protocols are allowed through the interface by default:

• DHCP
• DNS
• ICMP
• HTTPS

Ports for Controller Management

• Additional management protocols may be used on the VPN 512 interface of SD-WAN devices. They are summarized as follows:
• Summary of management protocols for SD-WAN devices

Service	Protocol/Port	Direction
NETCONF	TCP 830	Bidirectional
SSH	TCP 22	Incoming
SNMP Query	UDP 161	Incoming
Radius	UDP 1812	Outgoing
SNMP Trap	UDP 162	Outgoing
Syslog	UDP 514	Outgoing
TACACS	TCP 49	Outgoing
HTTPS (vManage)	TCP 443, 8443, 80	Incoming

Ports for vManage Clustering and Disaster Recovery

• For a vManage cluster, the following ports may be used on the cluster interface of the controllers. Ensure the correct ports are opened within firewalls that reside between cluster members.
• Summary of ports needed for vManage clustering

vManage Service	Protocol/Port	Direction
Application Server	TCP 80, 443, 7600, 8080, 8443, 57600	Bidirectional
Configuration Database	TCP 6362-6372, 7687, 7474, 5000, 6000, 7000	Bidirectional
Coordination Server	TCP 2181, 3888	Bidirectional
Message Bus	TCP 9092	Bidirectional
Statistics Database	TCP 9200, 9300	Bidirectional
Tracking of device configurations (NCS and NETCONF)	TCP 830	Bidirectional

• If disaster recovery is configured, ensure that the following ports are opened over the out-of-band interface across the data centers between the primary and standby cluster:
• Summary of ports needed for vManage disaster recovery

vManage Service	Protocol/Port	Direction
Disaster Recovery	TCP 443, 830, 18600, 18500, 18501, 18301, 18302, 18300	Bidirectional