What is DTLS?

Datagram Transport Layer Security (DTLS) is a protocol that provides TLS-equivalent authentication and encryption for connections carried over UDP instead of TCP. It preserves TLS’s security properties while tolerating packet loss and reordering, making it well suited to real-time and tunneled traffic – including Versa SASE client connections to a gateway.

Key takeaways

• DTLS ports TLS’s security guarantees onto UDP’s connectionless transport.
• It avoids TCP-over-TCP problems that plague TLS-in-tunnel deployments.
• DTLS 1.0 through 1.3 track the corresponding TLS protocol versions.
• Versa recommends DTLS over TLS for SASE client tunnels where supported.
• The Versa SASE client can use DTLS, IPsec, or TLS, in a configurable order.

On this page: Why it matters · How it works · Versions of DTLS · DTLS & Versa · FAQ

Why is DTLS important?

Many security-sensitive applications – VPN clients, voice and video, IoT telemetry – run over UDP because they need low latency and can tolerate occasional packet loss more gracefully than they can tolerate delay. Plain TLS cannot protect that traffic because TLS assumes a reliable, ordered TCP stream underneath it. Before DTLS existed, securing UDP traffic meant either accepting weaker, protocol-specific encryption or wrapping UDP inside a TCP-based TLS tunnel, which introduces a subtle but serious problem known as TCP-over-TCP meltdown.

DTLS solves this by re-implementing TLS’s handshake, cipher negotiation, and record protection to work directly over UDP, adding explicit sequence numbers and tolerance for lost or reordered handshake messages. That makes it possible to get TLS-grade authentication and confidentiality without forcing latency-sensitive or tunneled traffic through a TCP transport it was never designed for – which is exactly why VPN clients, including Versa’s, prefer it as a tunnel option when it’s available.

What is DTLS?

DTLS is defined as a set of modifications to TLS that let its handshake and record layer operate over an unreliable, unordered transport. The core building blocks are the same as TLS: a handshake that authenticates the server (and optionally the client) via certificates, negotiates a cipher suite, and derives session keys; and a record layer that encrypts and integrity-protects application data using those keys.

The differences address UDP’s lack of guarantees. DTLS adds explicit sequence numbers and an epoch value to detect and discard replayed or out-of-order records, a retransmission timer to recover handshake messages that UDP drops silently, and a stateless cookie exchange early in the handshake to resist denial-of-service attacks that try to exhaust server resources with spoofed connection attempts. The result is a protocol that a network engineer can reason about using the same mental model as TLS, while an implementation handles the UDP-specific reliability gaps underneath.

Versions of DTLS

DTLS versions track their TLS counterparts rather than following independent numbering. DTLS 1.0 corresponds to TLS 1.1, DTLS 1.2 corresponds to TLS 1.2 and is the version most widely deployed today, and DTLS 1.3 corresponds to TLS 1.3, bringing the same handshake simplification and stronger default cipher suites. There is no DTLS 1.1 in the version-number sequence – it was skipped so DTLS 1.2 would align with TLS 1.2.

Deployments typically configure a minimum and maximum acceptable version rather than pinning to one, letting two endpoints negotiate the strongest version and cipher suite they both support while rejecting anything below an administrator-set floor.

DTLS & Versa

DTLS is one of three tunnel types – alongside IPsec and TLS – that a Versa SASE client can use to reach a gateway, and Versa recommends it over TLS specifically to avoid TCP-over-TCP performance degradation when the client’s underlying network path is already unreliable. Administrators set the preferred sequence in the Tunnel Order field of the secure access server or gateway profile, choosing among DTLS, IPsec, and TLS, and the client tries them in that order.

Where DTLS is selected, the profile’s DTLS tab controls the minimum and maximum supported versions – the selector lists “DTLS 1.1”, 1.2, and 1.3, although no DTLS 1.1 was ever standardized (see the versions section above); the option label comes from the product GUI – plus the cipher suites offered, the DTLS port (default 443), and the DTLS profile ID, configured identically whether the secure access service is set up for Secure SD-WAN, general secure access, or NGFW deployments. These selectable ranges are what the Secure Access Service gateway configuration exposes; the SSL VPN profile documentation separately describes its tunnels as DTLS 1.2.

Frequently asked questions

What is the difference between TLS and DTLS?

TLS runs over TCP and relies on TCP for reliable, ordered delivery. DTLS runs over UDP and handles message loss, reordering, and retransmission itself, since UDP provides none of those guarantees. Both provide equivalent authentication and encryption.

Why avoid running TLS-based VPN tunnels over UDP-unfriendly paths?

Wrapping UDP-unaware TLS traffic inside another reliable transport, or forcing a TLS VPN’s TCP stream over an already-lossy path, causes TCP-over-TCP meltdown: nested retransmission timers compound delays and throughput collapses. DTLS avoids this because it never depends on an inner or outer TCP stream.

What DTLS versions does Versa support for SASE client tunnels?

The Versa Secure Access DTLS profile lets administrators select a minimum and maximum version, along with matching cipher suites, a DTLS port, and a profile ID; the maximum version must be equal to or later than the minimum. The version selector offers “DTLS 1.1”, DTLS 1.2, and DTLS 1.3 – note that “DTLS 1.1” is the label the product GUI shows even though the DTLS standard skipped 1.1 (the sequence runs 1.0, 1.2, 1.3), so prefer DTLS 1.2 or later when hardening a deployment.

Does DTLS use the same certificates as TLS?

Yes. DTLS reuses TLS’s certificate-based authentication model, so an endpoint’s existing server certificate and trust chain work for DTLS connections without separate certificate infrastructure. The client validates the gateway’s certificate during the handshake exactly as it would over TLS.

Why does DTLS include a cookie exchange in its handshake?

UDP has no connection setup, so an attacker can flood a server with spoofed handshake requests at minimal cost. The stateless cookie exchange makes the server verify the client’s address before committing resources to a full handshake, mitigating that denial-of-service pattern.

More on DTLS

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about DTLS, these are worth looking at next.