AnyConnect VPN DTLS vs TLS

Difference

DTLS is used for delay sensitive applications (voice and video) as its UDP based while TLS is TCP based

DTLS is supported for AnyConnect VPN not in IKEv2

How it works?

• SSL−Tunnel is the TCP tunnel that is first created to the ASA
• When it is fully established, the client will then try to negotiate a UDP DTLS−Tunnel
• During DTLS negotiation, traffic will be passing over TLS tunnel
• When the DTLS−Tunnel is fully established, all data now moves to the DTLS−tunnel and the SSL−tunnel is only used for occasional control channel traffic
• In case of failures in establishing DTLS Tunnel, traffic will continue passing over TLS tunnel
• After establishing DTLS, in the event of failure in DTLS Tunnel, traffic will pass over TLS tunnel until DTLS tunnel is reestablished

How Data is Forwarded?

• For each packet there is a part in AnyConnect client code which decides whether to send the packet over TLS or DTLS
• If the DTLS tunnel is established, the code will decide to forward the packet over DTLS and start encryption
• If the DTLS is dead, the code will decide to forward the packet over TLS and start encryption

• The key point is the performance of DTLS tunnel
• Since DTLS is based on UDP, it is unreliable and there is no flow control to decide its performance
• Performance can be determined using DPD packets
• When DPD is triggered and no response received, AnyConnect client will start forwarding packets over TLS (assuming TLS is up and DTLS is unhealthy)
• Therefore, there is a packet drop period between DTLS failing and DPD triggering/detection. During this time, AnyConnect client will be forwarding packets over DTLS but they will be lost because DTLS is unhealthy
• In case DTLS is established again, AnyConncect client will forward packets over DTLS
• For receiving ASA with healthy DTLS and TLS, it will reply based on the receiving tunnel, i.e. if packets received over TLS, the response will be over TLS even if DTLS is healthy

What about Idle timeout?

• When a DTLS−Tunnel is active, that is the only tunnel where idle timeout matters. Because very little control channel traffic passes over the SSL−Tunnel, it is almost always idle so it is exempt while there is an active DTLS−Tunnel. If something happened to UDP and the DTLS−Tunnel was torn down, then idle timeout would apply to the SSL−Tunnel

Configuration

DTLS is enabled by default but you can enable it or distable using CLI.

It can be enabled/disable per interface terminating AnyConnect VPN

webvpn

 enable if-name tls-only

Also, you can enable/disable DTLS at Group Policy level

webvpn

 dtls port 443

!

group-policy custom_group_policy attributes

 wins-server none

 dns-server value 10.170.7.99 10.170.7.100

 vpn-tunnel-protocol ssl-client ssl-clientless

 split-tunnel-policy tunnelspecified

 split-tunnel-network-list value sslvpn_split_tunnel

 default-domain value shelfdrilling.com

 split-dns none

 split-tunnel-all-dns enable

 webvpn

  anyconnect ssl dtls enable

  anyconnect mtu 1420

  anyconnect profiles value sslvpnfromrdpprofile type user

  customization value ShelfDrilling-Customization

  always-on-vpn profile-setting

The Importance of Understanding MTU value in AnyConnect VPN

Why do we need it?

During encryption, additional overhead will be added to the packets made by new headers and features. This means that the actual size of the unencrypted TCP segment or UDP datagram which holds the application will be reduced because the MTU of the adapter is still same.

For example with Ethernet and MTU of 1500-bytes, the unencrypted TCP segment can't be more than 1460-bytes. With encryption, for Ethernet and MTU of 1500, the unencrypted TCP segment can't be more 1380 (can be different value). The 80-bytes difference are utilized by encryption overhead.

Now the value of unencrypted TCP segment can be more which leads to MTU more than 1500-bytes but this will cause the networking devices to fragment the packet which is bad and should be avoided.

AnyConnect client builds Virtual Adapter (VA) during installation on the clients machine. This VA will receive unencrypted traffic and emulates Ethernet to forward traffic after encryption. The actual traffic then goes over the physical adapter.

Therefore, we need to know what is the MTU value of the VA and what is the max allowed size of unencrypted traffic to avoid fragmentation. Later the applications need to make sure that they don't create segments and datagrams larger else they will be fragmented.

How it works?

AnyConnect VA gets its MTU value from SSL Server (ASA or IOS. We will focus more on ASA). The default value is 1406-bytes. It can be configured as follow:

group-policy custom_group_policy attributes

 webvpn

  anyconnect mtu 1420

Now the actual MTU used by the VA will be selected based on the smaller between physical NIC MTU and VA configured MTU. This is to avoid scenarios where the VA has MTU configured more than physical NIC which will trigger fragmentation.

Next we need to find out the max value of unencrypted payload. Two values will be calculated, one for TLS Tunnel and one for DTLS tunnel. This can be viewed in ASA using the command debug webvpn anyconnect 1

……

……

Iphdr=20 base-mtu=1300 def-mtu=1500 conf-mtu=1420

tcp-mss = 1260

path-mtu = 1260(mss)

TLS Block size = 16, version = 0x301

mtu = 1260(path-mtu) - 0(opts) - 5(ssl) = 1255

mod-mtu = 1255(mtu) & 0xfff0(complement) = 1248

tls-mtu = 1248(mod-mtu) - 8(cstp) - 20(mac) - 1(pad) = 1219

DTLS Block size = 16

mtu = 1300(base-mtu) - 20(ip) - 8(udp) - 13(dtlshdr) - 16(dtlsiv) = 1243

mod-mtu = 1243(mtu) & 0xfff0(complement) = 1232

dtls-mtu = 1232(mod-mtu) - 1(cdtp) - 20(mac) - 1(pad) = 1210

computed tls-mtu=1219 dtls-mtu=1210 conf-mtu=1420

DTLS enabled for intf=2 (CORP)

tls-mtu=1219 dtls-mtu=1210

……

……

Let's examine the debugs

Iphdr=20 base-mtu=1300 def-mtu=1500 conf-mtu=1420

!!!... Iphdr is 20 bytes, Physical NIC MTU is 1300, configured MTU value for AnyConnect VA is 1420. Conclusion, Physical NIC MTU is used for VA.

!!!... Now will start TLS Tunnel calculations

tcp-mss = 1260

path-mtu = 1260(mss)

!!!... Since TLS is TCP based, the TLS payload size is MTU - 40. 40-bytes is 20-bytes IP Header + 20-bytes TCP Header

TLS Block size = 16, version = 0x301

mtu = 1260(path-mtu) - 0(opts) - 5(ssl) = 1255

mod-mtu = 1255(mtu) & 0xfff0(complement) = 1248

tls-mtu = 1248(mod-mtu) - 8(cstp) - 20(mac) - 1(pad) = 1219

!!!... Subtracting headers (5-bytes ssl header, 1-byte padding, 8-bytes Cisco SSL Tunneling Protocol (CSTP) header, 20-bytes MAC), we will get the size of unencrypted payload. This will be communicated back from ASA to AnyConnect client so that applications shouldn't cross this value else fragmentation will be triggered

!!!... Note: ANDing MSS value will complement 0xfff0 is to make sure that MSS value is power of 2

!!!... Now will start DTLS MTU calculations

DTLS Block size = 16

mtu = 1300(base-mtu) - 20(ip) - 8(udp) - 13(dtlshdr) - 16(dtlsiv) = 1243

mod-mtu = 1243(mtu) & 0xfff0(complement) = 1232

dtls-mtu = 1232(mod-mtu) - 1(cdtp) - 20(mac) - 1(pad) = 1210

!!!... Subtracting headers (20-bytes IP header, 8-bytes UDP header, 13-bytes DTLS header, 8- or 16- bytes for encryption [depending DES or AES], 1-byte Cisco DTLS Tunneling Protocol [CDTP] header, 20-bytes MAC, 1-byte pad), we will get the size of unencrypted payload. This will be communicated back from ASA to AnyConnect client so that applications shouldn't cross this value else fragmentation will be triggered

computed tls-mtu=1219 dtls-mtu=1210 conf-mtu=1420

DTLS enabled for intf=2 (CORP)

tls-mtu=1219 dtls-mtu=1210

Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a message and some secret data.  It is difficult to forge without knowing the secret data.  Its purpose is to detect if the message has been altered.