topic Enabling Data Link Encryption for Mobility Tunnels and APs? in Wireless

Enabling Data Link Encryption for Mobility Tunnels and APs?

coolbreeze — Fri, 19 Sep 2025 20:50:07 GMT

SCENARIO: A mix of physical and virtual Cisco 9800 wireless controllers in a wireless mobility anchoring configuration for guest tunneling of different SSIDs. The controllers are running 17.15.3 version of IOS XE. Approximately 150-200 APs in the wireless environment. Some SSIDs are doing FlexConnect in the policy at their local location.

GOAL: Looking at "secure mobility tunneling" and also enabling Data Link encryption for Access Points. This is the guide I was perusing so far for reference: https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_wl_16_10_cg/mobility.html

QUESTIONS:

1) Is DTLS encryption enabled by default for mobility peer tunnels?
2) For APs: I see EAP-FAST / CAPWAP DTLS + options in dropdowns for "AP Join Profile > AP > General > EAP Auth Configuration" for in a custom AP join profile - is that a different feature/function, and/or is DTLS enabled for CAPWAP tunnels on APs by default?

3) What are the benefits of enabling Data Link encryption for the mobility peer tunnel, and for APs?
4) Does it cause an impact/disruption when the option is enabled/checking the box and applying?
5) Are there any client / performance considerations/impact for data link encrypted mobility tunnels for guest traffic anchoring, and for data link encrypted APs for clients in general (not just guest traffic WLANS)?
6) What is the DTLS High Cipher Only toggle for Mobility in the GUI?
7) For mobility peers that are showing Data Link Encryption Disabled, do they require re-adding as peers (rebuilding the tunnel?) in order to edit or add Data Link Encryption for mobility peers/between anchors and foreign controllers?

AP Join Profile Options:

Mobility Configuration Toggle, & Mobility Peer Status:

Re: Enabling Data Link Encryption for Mobility Tunnels and APs?

Mark Elsen — Sat, 20 Sep 2025 10:59:14 GMT

- @coolbreeze 1) A 9800 based mobility tunnel is always secure and encrypted.

3) Confidentiality of mobility control/data traffic ; Align with regulatory requirements
(e.g., GDPR, ISO 27001) for encrypted inter-controller communication.

5) If anchor controller is overloaded due to DTLS processing, clients may see slower DHCP, captive portal redirects, or guest traffic latency.

6) You must enable High Cipher only if you require DTLS v1.2 encryption. The default value is Disabled. In disabled state, DTLS v1.0 encryption is enabled
If used the controllers advertise higher cipher suites during DTLS handshakes.
Verify the setting with : show wireless mobility summary | inc Cipher

7) You do not need to delete and re-add the mobility peer to enable DTLS encryption.
But The controllers will negotiate the DTLS handshake with the peer which may cause a short
latency effect on the mobility tunnels

Re: Enabling Data Link Encryption for Mobility Tunnels and APs?

coolbreeze — Mon, 22 Sep 2025 15:57:51 GMT

Thanks @Mark Elsen ! I realized I mistyped a bit, can you help demystify what is the difference for enabling "Data Encryption" and "Data Link Encryption"? I noticed my mobility peer screenshot shows Data Link Encryption Disabled so am confused on that (unless it would pertain only to v1.2 encryption being enabled as you mentioned in #6).

Is encryption for data (higher layer/payload information) included, or is it just CAPWAP control packets on APs and mobility tunnel inter-controller packets?

Still wondering what that checkbox "Enable Data Encryption" will do for AP join profile, and the impact, assuming it is something different than DTLS.

Re: Enabling Data Link Encryption for Mobility Tunnels and APs?

Mark Elsen — Mon, 22 Sep 2025 16:29:36 GMT

- @coolbreeze Enable Data Encryption enables Datagram Transport Layer Security (DTLS) data encryption
So that applies to simple/single DTLS connections only

Data link encryption (encrypting client data traffic between controllers)
is optional and is recommended if a mobility tunnel is built on top of a nontrusted network.
It is disabled by default, and if enabled, it has to be done on both sides.