Anyconnect DPD causing reconnects.

fmoghimi · ‎04-30-2021

Hello

We recently got a client that is experiencing multiple reconnects a day. We made him try on a different pc, and even let him connect with his mobile data. None have fixed the issue. I went through the DART bundle and I found the following Error message:

******************************************

Date : 04/28/2021
Time : 14:10:40
Type : Error
Source : acvpnagent

Description : Function: CTunnelProtocolDpdMgr::OnTimerExpired
File: \vpn\agent\tunnelprotocoldpdmgr.cpp
Line: 304
Invoked Function: CTunnelProtocolDpdMgr::handleExpiredDPD
Return Code: -25952246 (0xFE74000A)
Description: TUNNELPROTOCOLDPDMGR_ERROR_NO_DPD_RESPONSE:The secure gateway failed to respond to Dead Peer Detection packets.
SSL/CSTP

******************************************

Date : 04/28/2021
Time : 14:10:40
Type : Error
Source : acvpnagent

Description : Function: CTunnelStateMgr::OnTunnelStatusChange
File: \vpn\agent\tunnelstatemgr.cpp
Line: 1421
Invoked Function: Tunnel status change callback status
Return Code: -25952246 (0xFE74000A)
Description: TUNNELPROTOCOLDPDMGR_ERROR_NO_DPD_RESPONSE:The secure gateway failed to respond to Dead Peer Detection packets.
SSL

******************************************

Date : 04/28/2021
Time : 14:10:40
Type : Warning
Source : acvpnagent

Description : Tunnel level reconnect reason code 6:
Disruption of the VPN connection to the secure gateway.
Caching the default reconnect reason for SSL

******************************************

Date : 04/28/2021
Time : 14:10:40
Type : Information
Source : acvpnagent

Description : The Primary SSL connection to the secure gateway is being re-established.

******************************************

Now I'm almost completely new to ASA, I just started working at this company as junior Network Engineer.

My question is, will lowering the DPD interval fix this issue? I couldn't really find an answer for this, the only thing I've found is people saying change the dpd timer, but not if I should change it to a lower or higher value. But just to be sure I wanted to ask here, If i set the dpd interval to a lower value, this means that dpd packets will be sent more frequently and that should fix the issue right?

Thanks in advance!

Steven Case · ‎04-30-2021

It is odd that only one client is experiencing this issue on multiple devices.

But to answer your question: yes. The amount of seconds is what you are defining on the detection. However, this means it should receive in that time, not necessarily that it will solicit.

The one document I found had a time on it, and actually increased the time to 266% the original value (from 30s default to 80s), so keep that in mind. This would give the server side more time to wait for the packet, instead of killing a connection based on latency, bumps, or just plain old TCP doing what TCP does sometimes.

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-firewalls/212972-anyconnect-vpn-client-troubleshooting-gu.html

fmoghimi · ‎04-30-2021

Thank you for your answer!

So I should increase the interval then? I've already seen the link you provided but I got confused about the other commands where they set the interval to 5 seconds. The value we are using now is 60 seconds. I need to send a change request because Im not allowed to change the interval without approval. I might set it to 80 or 100 to test if the problem will be fixed.

So just so I'm 100 percent sure about this, the 60 seconds is the time that the client or server waits to receive a DPD packet before closing? So that means the client is not receiving a DPD packet from our ASA in 60 seconds and therefore closes the VPN connection?

Steven Case · ‎04-30-2021

Correct. It's kind of like some of the routing and routed protocol K-values in which there are timeframes to receive a "HELLO" packet. If it doesn't receive a HELLO from the client in that window it will drop the connection as detached or disconnected.

Something to note on K-Value manipulation: it rarely matters outside of routing protocols (even then... it varies amongst topologies). Meaning you can set it to 80s or 100s with little-to-no impact to the majority of connections. What this does is simply ... distract things that rely on highly reliable traffic.

Take VPN for instance. Just because you're connected doesn't mean you're doing a bunch of stuff on that tunnel (especially if you're doing split tunneling and relegating web traffic over the remote network and not your own). So, the state of that connection is seen as "UP" until otherwise proven (using the DPD and other criteria). Well, now you want to reauth or some other fancy thing with ISE, RADIUS, RFC 5176, whatever you want and you think that client is up. However, 20s ago it actually had a power outage on the other end.

What's the end result? Wasted electricity that doesn't even amount to lighting an LED. Whereas if the timer was set in such a way that it was discovered as DOWN and wouldn't even attempt, it sent out the RFC 5176 packet to something that isn't going to respond because it was "UP". Well, that will time out and life will continue unabated. No big deal.

I bring this up for your CM knowledge is all. You'll want to sound like a pro if your CM is anything like mine. Sadly, I'm the Principal, and find myself arguing with individuals who think next-generation is a iPhone 2.

MHM Cisco World · ‎04-30-2021

increase the inactivity time, where when ASA send DPD and not get response from client, the ASA will delete the session tunnel but not the Parent Tunnel, and this Parent tunnel will long as inactivity time, if the client is return within this time no problem if the client return after this time then the ASA will ask reconnect .