■ Environment
- AnyConnect client: 4.09
- OS: macOS Sonoma
- VPN gateway: Cisco ASA
- Connection: SSL-VPN (AnyConnect), split-tunnel enabled
■ Symptom
- VPN connects successfully and the client receives a correct IP.
- Exactly ~60 seconds after connection, the session always disconnects once.
- It auto-reconnects within a few seconds and then remains stable for 20+ minutes.
- This “one drop at ~1 minute” happens every time. I want to eliminate it.
■ Scope
- Occurs on one specific client endpoint only.
- Other users on the same profile are stable (no disconnect).
- On the ASA, the user is admitted correctly, no license issues, and no abnormalities except the ~60s disconnect event.
■ Logs
- AnyConnect Message History records a disconnect exactly ~1 minute after connection.
- Endpoint logs under /opt/cisco/anyconnect/logs/ (vpn.log, acvpnagent.log) show tunnel down at ~60s → immediate reconnect.
- Not a network stability issue (reproduces on both wired and Wi-Fi).
■ Already verified
- Destination networks are included in split-tunnel; routing is correct.
- No ASA firewall rule blocks this user.
- ASA syslog shows no abnormality other than the disconnect event.
■ Questions (DTLS cannot be disabled; seeking concrete fixes)
1) Permanent fix while keeping DTLS enabled
- To eliminate the first-minute drop, what ASA DTLS-related settings (with recommended values) should we review/tune?
Examples: best practices for UDP/443 reachability and NAT traversal, MTU/MSS tuning (recommended range), fragment allowance, required ACL/NAT rules, and DPD/Keepalive values that worked in the field.
- For macOS Sonoma + AnyConnect 4.09, are there known issues where DTLS handshake/keepalive fails around 1 minute and falls back to TCP?
If so, please share recommended client version (upgrade/downgrade targets) and any profile options that resolve it.
(DTLS must remain enabled; we need a solution that continues to use DTLS.)
2) Per-user workaround (keep DTLS globally)
- Without changing global settings, is there a best practice to make only a specific user/group prefer TLS (or force TLS)?
If yes, which is recommended—client XML profile, group-policy, or tunnel-group—and could you provide exact ASDM/CLI steps?
(Global DTLS disable is not possible; we need a scoped workaround.)
3) Evidence to confirm DTLS as root cause (what to capture)
- With DTLS kept enabled, which ASA syslog IDs/reason codes and which client log messages (e.g., “DTLS negotiation failed”, “handshake timeout”, “DPD failed”) are the decisive indicators?
- Once that evidence is captured, which settings (and what values) should be changed to stop the recurrence? Real-world examples are especially helpful.
4) Prioritized action plan (requested)
- Given DTLS must stay on, could you propose a priority-ordered runbook that has worked to stop this issue in the field? For example:
(1) MTU/MSS optimization (recommended values) → (2) Verify UDP/443, NAT, fragmentation → (3) Adjust DPD/Keepalive (recommended intervals) → (4) Update client version / profile options, ...
Please include the actual values that resolved it.
Goal: identify exact settings/values and steps (ASA and/or client) that permanently prevent the single disconnect at ~60s while continuing to use DTLS. Command paths or ASDM screenshots/paths are very welcome.
