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