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
