If you configure the Cisco SD-WAN Manager to use TLS as the control plane security protocol, you must enable port forwarding on your NAT. If you are using DTLS as the control plane security protocol, you do not need to do anything.

The number of ports forwarded depends on the number of vdaemon processes running on the Cisco SD-WAN Manager. To display information about these processes and about and the number of ports that are being forwarded, use the show control summary command shows that four vdaemon processes are running:

vManage# show control summary
          VBOND     VMANAGE    VSMART    VEDGE
INSTANCE  COUNTS    COUNTS     COUNTS    COUNTS
------------------------------------------------
0           2          0           2        7
1           2          0           0        5
2           2          0           0        5
3           2          0           0        4

To see the listening ports, use the show control local-properties command:

vManage# show control local-properties

organization-name            Cisco SD-WAN Inc Test
certificate-status           Installed
root-ca-chain-status         Installed

certificate-validity         Valid
certificate-not-valid-before May 20 00:00:00 2015 GMT
certificate-not-valid-after  May 20 23:59:59 2016 GMT

dns-name                     vbond.cisco.com
site-id                      5000
domain-id                    0
protocol                     dtls
​tls-port                     23456
...
...
...
number-active-wan-interfaces 1

                PUBLIC       PUBLIC PRIVATE       PRIVATE                                   ADMIN  OPERATION LAST
INDEX INTERFACE IP           PORT   IP            PORT    VSMARTS  VMANAGES COLOR  CARRIER  STATE  STATE     CONNECTION
------------------------------------------------------------------------------------------------------------------------
0     eth0      72.28.108.37 12361  172.16.98.150 12361   2        0        silver default  up     up       0:00:00:08

This output shows that the listening TCP port is 23456. If you are running Cisco SD-WAN Manager behind a NAT, you should open the following ports on the NAT device:

• 23456 (base - instance 0 port)

• 23456 + 100 (base + 100)

• 23456 + 200 (base + 200)

• 23456 + 300 (base + 300)

Note that the number of instances is the same as the number of cores you have assigned for the Cisco SD-WAN Manager, up to a maximum of 8.

Before Cisco IOS XE Catalyst SD-WAN devices and Cisco vEdge devices can exchange data traffic, they set up a secure authenticated communications channel between them. The routers use IPSec tunnels between them as the channel, and the AES-256 cipher to perform encryption. Each router generates a new AES key for its data path periodically.

By default, a key is valid for 86400 seconds (24 hours), and the timer range is 10 seconds through 1209600 seconds (14 days). To change the rekey timer value:

Device(config)# security ipsec 
rekey seconds

The configuration looks like this:

security  
    ipsec    
      rekey seconds
    !

If you want to generate new IPsec keys immediately, you can do so without modifying the configuration of the router. To do this, issue the request security ipsec-rekey command on the compromised router.

For example, the following output shows that the local SA has a Security Parameter Index (SPI) of 256:

Device# show ipsec local-sa
         
                                          SOURCE           SOURCE             
TLOC ADDRESS     TLOC COLOR       SPI     IP               PORT    KEY HASH   
------------------------------------------------------------------------------
172.16.255.15    lte              256     10.1.15.15       12346   *****b93a 

A unique key is associated with each SPI. If this key is compromised, use the request security ipsec-rekey command to generate a new key immediately. This command increments the SPI. In our example, the SPI changes to 257 and the key associated with it is now used:

Device# request security ipsec-rekey
Device# show ipsec local-sa
                                          SOURCE           SOURCE             
TLOC ADDRESS     TLOC COLOR       SPI     IP               PORT    KEY HASH   
------------------------------------------------------------------------------
172.16.255.15    lte              257     10.1.15.15       12346   *****b93a 

After the new key is generated, the router sends it immediately to the Cisco SD-WAN Controllers using DTLS or TLS. The Cisco SD-WAN Controllers send the key to the peer routers. The routers begin using it as soon as they receive it. Note that the key associated with the old SPI (256) will continue to be used for a short period of time, until it times out.

To stop using the old key immediately, issue the request security ipsec-rekey command twice, in quick succession. This sequence of commands removes both SPI 256 and 257 and sets the SPI to 258. The router then uses the associated key of SPI 258. Note, however, that some packets will be dropped for a short period of time, until all the remote routers learn the new key.

Device# request security ipsec-rekey
Device# request security ipsec-rekey
Device# ipsec local-sa
                                          SOURCE           SOURCE             
TLOC ADDRESS     TLOC COLOR       SPI     IP               PORT    KEY HASH   
------------------------------------------------------------------------------
172.16.255.15    lte              258     10.1.15.15       12346   *****b93a 

IPsec authentication provides anti-replay protection by assigning a unique sequence number to each packet in a data stream. This sequence numbering protects against an attacker duplicating data packets. With anti-replay protection, the sender assigns monotonically increasing sequence numbers, and the destination checks these sequence numbers to detect duplicates. Because packets often do not arrive in order, the destination maintains a sliding window of sequence numbers that it will accept.

Packets with sequence numbers that fall to the left of the sliding window range are considered old or duplicates, and the destination drops them. The destination tracks the highest sequence number it has received, and adjusts the sliding window when it receives a packet with a higher value.

By default, the sliding window is set to 512 packets. It can be set to any value between 64 and 4096 that is a power of 2 (that is, 64, 128, 256, 512, 1024, 2048, or 4096). To modify the anti-replay window size, use the replay-window command, specifying the size of the window:

Device(config)# security ipsec replay-window 
number

The configuration looks like this:

security  
   ipsec
     replay-window number
   !
!

To help with QoS, separate replay windows are maintained for each of the first eight traffic channels. The configured replay window size is divided by eight for each channel.

If QoS is configured on a router, that router might experience a larger than expected number of packet drops as a result of the IPsec anti-replay mechanism, and many of the packets that are dropped are legitimate ones. This occurs because QoS reorders packets, giving higher-priority packets preferential treatment and delaying lower-priority packets. To minimize or prevent this situation, you can do the following:

• Increase the size of the anti-replay window.

• Engineer traffic onto the first eight traffic channels to ensure that traffic within a channel is not reordered.

To configure an IPsec tunnel interface for secure transport traffic from a service network, you create a logical IPsec interface:

vEdge(config)# vpn vpn-id interface ipsecnumber
vEdge(config-interface-ipsec)# ip address ipv4-prefix/length
vEdge(config-interface-ipsec)# tunnel-source ip-address | tunnel-source-interface interface-name)
vEdge(config-interface-ipsec)# tunnel-destination ipv4-address
vEdge(config-interface-ipsec)# no shutdown 

You can create the IPsec tunnel in the transport VPN (VPN 0) and in any service VPN (VPN 1 through 65530, except for 512).

The IPsec interface has a name in the format ipsecnumber, where number can be from 1 through 255.

Each IPsec interface must have an IPv4 address. This address must be a /30 prefix. All traffic in the VPN that is within this IPv4 prefix is directed to a physical interface in VPN 0 to be sent securely over an IPsec tunnel.

To configure the source of the IPsec tunnel on the local device, you can specify either the IP address of the physical interface (in the tunnel-source command) or the name of the physical interface (in the tunnel-source-interface command). Ensure that the physical interface is configured in VPN 0.

To configure the destination of the IPsec tunnel, specify the IP address of the remote device in the tunnel-destination command.

The combination of a source address (or source interface name) and a destination address defines a single IPsec tunnel. Only one IPsec tunnel can exist that uses a specific source address (or interface name) and destination address pair.

To direct traffic from the service VPN to an IPsec tunnel in the transport VPN (VPN 0), you configure an IPsec-specific static route in a service VPN (a VPN other than VPN 0 or VPN 512) :

vEdge(config)# vpn vpn-id
vEdge(config-vpn)# ip ipsec-route prefix/length vpn 0 interface 
ipsecnumber [ipsecnumber2]

The VPN ID is that of any service VPN (VPN 1 through 65530, except for 512).

prefix/length is the IP address or prefix, in decimal four-part-dotted notation, and prefix length of the IPsec-specific static route.

The interface is the IPsec tunnel interface in VPN 0. You can configure one or two IPsec tunnel interfaces. If you configure two, the first is the primary IPsec tunnel, and the second is the backup. With two interfaces, all packets are sent only to the primary tunnel. If that tunnel fails, all packets are then sent to the secondary tunnel. If the primary tunnel comes back up, all traffic is moved back to the primary IPsec tunnel.

When you create an IPsec tunnel on a vEdge router, IKE Version 1 is enabled by default on the tunnel interface. The following properties are also enabled by default for IKEv1:

• Authentication and encryption—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity

• Diffie-Hellman group number—16

• Rekeying time interval—4 hours

• SA establishment mode—Main

By default, IKEv1 uses IKE main mode to establish IKE SAs. In this mode, six negotiation packets are exchanged to establish the SA. To exchange only three negotiation packets, enable aggressive mode:

Note	IKE aggressive mode with pre-shared keys should be avoided wherever possible. Otherwise a strong pre-shared key should be chosen.

vEdge(config)# vpn vpn-id interface ipsec number ike
vEdge(config-ike)# mode aggressive 

By default, IKEv1 uses Diffie-Hellman group 16 in the IKE key exchange. This group uses the 4096-bit more modular exponential (MODP) group during IKE key exchange. You can change the group number to 2 (for 1024-bit MODP), 14 (2048-bit MODP), or 15 (3072-bit MODP):

vEdge(config)# vpn vpn-id interface ipsec number ike
vEdge(config-ike)# group number

By default, IKE key exchange uses AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity. You can change the authentication:

vEdge(config)# vpn vpn-id interface ipsec number ike 
vEdge(config-ike)# cipher-suite suite

The authentication suite can be one of the following:

• aes128-cbc-sha1—AES-128 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity

• aes128-cbc-sha2—AES-128 advanced encryption standard CBC encryption with the HMAC-SHA256 keyed-hash message authentication code algorithm for integrity

• aes256-cbc-sha1—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity; this is the default.

• aes256-cbc-sha2—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA256 keyed-hash message authentication code algorithm for integrity

By default, IKE keys are refreshed every 1 hours (3600 seconds). You can change the rekeying interval to a value from 30 seconds through 14 days (1209600 seconds). It is recommended that the rekeying interval be at least 1 hour.

vEdge(config)# vpn vpn-id interface ipsec number ike
vEdge(config-ike)# rekey seconds

To force the generation of new keys for an IKE session, issue the request ipsec ike-rekey command.

vEdge(config)# vpn vpn-id interfaceipsec number ike 

For IKE, you can also configure preshared key (PSK) authentication:

vEdge(config)# vpn vpn-id interface ipsec number ike
vEdge(config-ike)# authentication-type pre-shared-key pre-shared-secret password

password is the password to use with the preshared key. It can be an ASCII or a hexadecimal string from 1 through 127 characters long.

If the remote IKE peer requires a local or remote ID, you can configure this identifier:

vEdge(config)# vpn vpn-id interface ipsec number ike authentication-type
vEdge(config-authentication-type)# local-id id
vEdge(config-authentication-type)# remote-id id

The identifier can be an IP address or any text string from 1 through 63 characters long. By default, the local ID is the tunnel's source IP address and the remote ID is the tunnel's destination IP address.

When you configure an IPsec tunnel to use IKE Version 2, the following properties are also enabled by default for IKEv2:

• Authentication and encryption—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity

• Diffie-Hellman group number—16

• Rekeying time interval—4 hours

By default, IKEv2 uses Diffie-Hellman group 16 in the IKE key exchange. This group uses the 4096-bit more modular exponential (MODP) group during IKE key exchange. You can change the group number to 2 (for 1024-bit MODP), 14 (2048-bit MODP), or 15 (3072-bit MODP):

vEdge(config)# vpn vpn-id interface ipsecnumber ike 
vEdge(config-ike)# group number

By default, IKE key exchange uses AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity. You can change the authentication:

vEdge(config)# vpn vpn-id interface ipsecnumber ike
vEdge(config-ike)# cipher-suite suite

The authentication suite can be one of the following:

• aes128-cbc-sha1—AES-128 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity

• aes128-cbc-sha2—AES-128 advanced encryption standard CBC encryption with the HMAC-SHA256 keyed-hash message authentication code algorithm for integrity

• aes256-cbc-sha1—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication code algorithm for integrity; this is the default.

• aes256-cbc-sha2—AES-256 advanced encryption standard CBC encryption with the HMAC-SHA256 keyed-hash message authentication code algorithm for integrity

By default, IKE keys are refreshed every 4 hours (14,400 seconds). You can change the rekeying interval to a value from 30 seconds through 14 days (1209600 seconds):

vEdge(config)# vpn vpn-id interface ipsecnumber ike
vEdge(config-ike)#  rekey seconds

To force the generation of new keys for an IKE session, issue the request ipsec ike-rekey command.

For IKE, you can also configure preshared key (PSK) authentication:

vEdge(config)# vpn vpn-id interface ipsecnumber ike
vEdge(config-ike)# authentication-type pre-shared-key pre-shared-secret password

password is the password to use with the preshared key. It can be an ASCII or a hexadecimal string, or it can be an AES-encrypted key.

If the remote IKE peer requires a local or remote ID, you can configure this identifier:

vEdge(config)# vpn vpn-id interface ipsecnumber ike authentication-type 
vEdge(config-authentication-type)# local-id id
vEdge(config-authentication-type)# remote-id id

The identifier can be an IP address or any text string from 1 through 64 characters long. By default, the local ID is the tunnel's source IP address and the remote ID is the tunnel's destination IP address.

By default, the following parameters are used on the IPsec tunnel that carries IKE traffic:

• Authentication and encryption—AES-256 algorithm in GCM (Galois/counter mode)

• Rekeying interval—4 hours

• Replay window—32 packets

You can change the encryption on the IPsec tunnel to the AES-256 cipher in CBC (cipher block chaining mode, with HMAC using either SHA-1 or SHA-2 keyed-hash message authentication or to null with HMAC using either SHA-1 or SHA-2 keyed-hash message authentication, to not encrypt the IPsec tunnel used for IKE key exchange traffic:

vEdge(config-interface-ipsecnumber)# ipsec 
vEdge(config-ipsec)# cipher-suite (aes256-gcm | aes256-cbc-sha1 | aes256-cbc-sha256 | aes256-cbc-sha384 | aes256-cbc-sha512 | aes256-null-sha1 | aes256-null-sha256 | aes256-null-sha384 | aes256-null-sha512)

By default, IKE keys are refreshed every 4 hours (14,400 seconds). You can change the rekeying interval to a value from 30 seconds through 14 days (1209600 seconds):

vEdge(config-interface-ipsecnumber)# ipsec
vEdge(config-ipsec)#  rekey seconds

To force the generation of new keys for an IPsec tunnel, issue the request ipsec ipsec-rekey command.

By default, perfect forward secrecy (PFS) is enabled on IPsec tunnels, to ensure that past sessions are not affected if future keys are compromised. PFS forces a new Diffie-Hellman key exchange, by default using the 4096-bit Diffie-Hellman prime module group. You can change the PFS setting:

vEdge(config-interface-ipsecnumber)# ipsec
vEdge(config-ipsec)# perfect-forward-secrecy pfs-setting

pfs-setting can be one of the following:

• group-2—Use the 1024-bit Diffie-Hellman prime modulus group.

• group-14—Use the 2048-bit Diffie-Hellman prime modulus group.

• group-15—Use the 3072-bit Diffie-Hellman prime modulus group.

• group-16—Use the 4096-bit Diffie-Hellman prime modulus group. This is the default.

• none—Disable PFS.

By default, the IPsec replay window on the IPsec tunnel is 512 bytes. You can set the replay window size to 64, 128, 256, 512, 1024, 2048, or 4096 packets:

vEdge(config-interface-ipsecnumber)# ipsec
vEdge(config-ipsec)# replay-window number

IKE uses a dead-peer detection mechanism to determine whether the connection to an IKE peer is functional and reachable. To implement this mechanism, IKE sends a Hello packet to its peer, and the peer sends an acknowledgment in response. By default, IKE sends Hello packets every 10 seconds, and after three unacknowledged packets, IKE declares the neighbor to be dead and tears down the tunnel to the peer. Thereafter, IKE periodically sends a Hello packet to the peer, and re-establishes the tunnel when the peer comes back online.

You can change the liveness detection interval to a value from 0 through 65535, and you can change the number of retries to a value from 0 through 255.

Note

For transport VPNs, the liveness detection interval is converted to seconds by using the following formula: Interval for retransmission attempt number N = interval * 1.8N-1 For example, if the interval is set to 10 and retries to 5, the detection interval increases as follows: Attempt 1: 10 * 1.81-1= 10 seconds Attempt 2: 10 * 1.82-1= 18 seconds Attempt 3: 10 * 1.83-1= 32.4 seconds Attempt 4: 10 * 1.84-1= 58.32 seconds Attempt 5: 10 * 1.85-1= 104.976 seconds

vEdge(config-interface-ipsecnumber)# dead-peer-detection interval retries number

For IPsec tunnel interfaces, you can configure only the following additional interface properties:

vEdge(config-interface-ipsec)# mtu bytes
vEdge(config-interface-ipsec)# tcp-mss-adjust bytes

Cisco SD-WAN Manager provides an SSH client for communication with components in the network, including controllers and edge devices. The SSH client provides an encrypted connection for secure data transfer, based on a variety of encryption algorithms. Many organizations require stronger encryption than that provided by SHA-1, AES-128, and AES-192.

From Cisco vManage Release 20.9.1, you can disable the following weaker encryption algorithms so that an SSH client does not use these algorithms:

• SHA-1

• AES-128

• AES-192

Before disabling these encryption algorithms, ensure that Cisco vEdge devices, if any, in the network, are using a software release later than Cisco SD-WAN Release 18.4.6.

1. From the Cisco SD-WAN Manager menu, choose Tools > SSH Terminal.

2. Choose the Cisco SD-WAN Manager device on which you wish to disable weaker SSH algorithms.

3. Enter the username and password to log in to the device.

4. Enter SSH server mode.

   vmanage# config terminal

   vmanage(config)# system

   vmanage(config-system)# ssh-server

5. Do one of the following to disable an SSH encryption algorithm:

   • Disable SHA-1:

     1. vmanage(config-ssh-server)# no kex-algo sha1

     2. vmanage(config-ssh-server)# commit

        The following warning message is displayed:

        The following warnings were generated:
        'system ssh-server kex-algo sha1': WARNING: Please ensure all your edges run code version > 18.4.6 which negotiates better than SHA1 with vManage. Otherwise those edges may become offline.
        Proceed? [yes,no] yes

     3. Ensure that any Cisco vEdge devices in the network are running Cisco SD-WAN Release 18.4.6 or later and enter yes.

   • Disable AES-128 and AES-192:

     1. vmanage(config-ssh-server)# no cipher aes-128-192

     2. vmanage(config-ssh-server)# commit

        The following warning message is displayed:

        The following warnings were generated:
        'system ssh-server cipher aes-128-192': WARNING: Please ensure all your edges run code version > 18.4.6 which negotiates better than AES-128-192 with vManage. Otherwise those edges may become offline.
        Proceed? [yes,no] yes

     3. Ensure that any Cisco vEdge devices in the network are running Cisco SD-WAN Release 18.4.6 or later and enter yes.

1. From the Cisco SD-WAN Manager menu, choose Tools > SSH Terminal.

2. Select the Cisco SD-WAN Manager device you wish to verify.

3. Enter the username and password to log in to the device.

4. Run the following command:

   show running-config system ssh-server

5. Confirm that the output shows one or more of the commands that disable weaker encryption algorithms:

   • no cipher aes-128-192

   • no kex-algo sha1