cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
40790
Views
45
Helpful
9
Replies

AnyConnect client reconnects after 1 minute

Johan.Broer
Level 1
Level 1

AnyConnect client reconnects after 1 minute; WHY

version 3.1.02026

ASA:asa911-k8.bin

[25-4-2013 8:16:11] Establishing VPN session...

[25-4-2013 8:16:11] Checking for profile updates...

[25-4-2013 8:16:11] Checking for product updates...

[25-4-2013 8:16:11] Checking for customization updates...

[25-4-2013 8:16:11] Performing any required updates...

[25-4-2013 8:16:12] Establishing VPN session...

[25-4-2013 8:16:12] Establishing VPN - Initiating connection...

[25-4-2013 8:16:12] Establishing VPN - Examining system...

[25-4-2013 8:16:12] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:16:15] Establishing VPN - Configuring system...

[25-4-2013 8:16:16] Establishing VPN...

[25-4-2013 8:16:16] Connected to my.vpn.com.

[25-4-2013 8:16:16] Connected to my.vpn.com.

[25-4-2013 8:17:19] Reconnecting to my.vpn.com...

[25-4-2013 8:17:19] Establishing VPN - Examining system...

[25-4-2013 8:17:24] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:17:25] Establishing VPN - Configuring system...

[25-4-2013 8:17:25] Establishing VPN...

[25-4-2013 8:17:25] Connected to my.vpn.com.

[25-4-2013 8:17:25] Reconnecting to my.vpn.com...

[25-4-2013 8:17:25] Establishing VPN - Examining system...

[25-4-2013 8:17:25] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:17:25] Establishing VPN - Configuring system...

[25-4-2013 8:17:25] Establishing VPN...

[25-4-2013 8:17:25] Connected to my.vpn.com.

[25-4-2013 8:16:11] Establishing VPN session...

[25-4-2013 8:16:11] Checking for profile updates...

[25-4-2013 8:16:11] Checking for product updates...

[25-4-2013 8:16:11] Checking for customization updates...

[25-4-2013 8:16:11] Performing any required updates...

[25-4-2013 8:16:12] Establishing VPN session...

[25-4-2013 8:16:12] Establishing VPN - Initiating connection...

[25-4-2013 8:16:12] Establishing VPN - Examining system...

[25-4-2013 8:16:12] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:16:15] Establishing VPN - Configuring system...

[25-4-2013 8:16:16] Establishing VPN...

[25-4-2013 8:16:16] Connected to my.vpn.com.

[25-4-2013 8:16:16] Connected to my.vpn.com.

[25-4-2013 8:17:19] Reconnecting to my.vpn.com...

[25-4-2013 8:17:19] Establishing VPN - Examining system...

[25-4-2013 8:17:24] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:17:25] Establishing VPN - Configuring system...

[25-4-2013 8:17:25] Establishing VPN...

[25-4-2013 8:17:25] Connected to my.vpn.com.

[25-4-2013 8:17:25] Reconnecting to my.vpn.com...

[25-4-2013 8:17:25] Establishing VPN - Examining system...

[25-4-2013 8:17:25] Establishing VPN - Activating VPN adapter...

[25-4-2013 8:17:25] Establishing VPN - Configuring system...

[25-4-2013 8:17:25] Establishing VPN...

[25-4-2013 8:17:25] Connected to my.vpn.com.

3 Accepted Solutions

Accepted Solutions

Shaoqin Li
Level 3
Level 3

the log is not sufficient

get more log from asa

Sent from Cisco Technical Support iPad App

View solution in original post

gwes
Level 1
Level 1

I’ve been having this for a while now. But other problems kept me from further investigating this issue. It a nagging problem, but after the reconnect everything is ok. So because of that, this one was not so high in my list of issue’s to solve. I suspected this to be a client thing. I’ve seen the same problem on windows7 and windows8 clients. I don’t know exactly when this problem started, but after installing the latest client 3.1.0459 the problem was not fixed. By now I would assume that Cisco would have fixed this bug, so I now started to suspect the firmware or VPN configuration of our ASA. Which was running 9.1 software. I started by doing a:

# debug webvpn anyconnect 255

After looking at the logs something caught my eye

Group User < omitted > IP < omitted > Transmitting large packet 1418 (threshold 1331).

What the??? What is this? After using google, I found this document.

Error:− %ASA−6−722036: Group client−group User xxxx IP x.x.x.x Transmitting large packet 1220 (threshold 1206)
The %ASA−6−722036: Group < client−group > User < xxxx > IP < x.x.x.x>
Transmitting large packet 1220 (threshold 1206)
error message appears in the logs of
the ASA. What does this log mean and how is this resolved?
Solution:
This log message states that a large packet was sent to the client. The source of the packet is not aware of the
MTU of the client. This can also be due to compression of non−compressible data. The workaround is to turn
off the SVC compression with the svc compression none command. This resolves the issue.

After applying these rules to the group policy configuration my problem was gone

webvpn
   anyconnect mtu 1331
   anyconnect ssl compression none

http://www.cyu.nl/anyconnect-reconnects-after-1-minute/

View solution in original post

Hello Michael,

The problem here is because we cannot succesfully establish a DTLS tunnel. This could happen because:

- DTLS is blocked somewhere in the path

- A non-default DTLS port is being used

If DTLS is blocked in the middle the issue is because as of ASA Release 9.x and AnyConnect Release 3.x, an optimization has been introduced in the form of distinct Maximum Transition Units (MTUs) that are negotiated for TLS/DTLS between the client/ASA. Previously, the client derived a rough estimate MTU which covered both TLS/DTLS and was obviously less than optimal. Now, the ASA computes the encapsulation overhead for both TLS/DTLS and derives the MTU values accordingly.

As long as DTLS is enabled, the client applies the DTLS MTU (in this case 1418) on the VPN adapter (which is enabled before the DTLS tunnel is established and is needed for routes/filters enforcement), to ensure optimum performance. If the DTLS tunnel cannot be established or it is dropped at some point, the client fails over to TLS and adjusts the MTU on the virtual adapter (VA) to the TLS MTU value (this requires a session level reconnect).

In order to eliminate this visible transition of DTLS > TLS,  you can configure a separate tunnel group for TLS only access for users that have trouble with the establishment of the DTLS tunnel (such as due to firewall restrictions).

1. The best option is to set the AnyConnect MTU value to be lower than the TLS MTU, which is then negotiated.

group-policy ac_users_group attributes

webvpn

  anyconnect mtu 1300

This makes TLS and DTLS MTU values equal. Reconnections are not seen in this case.

2. The second option is to allow fragmentation.

group-policy ac_users_group attributes

webvpn

  anyconnect ssl df-bit-ignore enable

With fragmentation, large packets (whose size exceeds the MTU value) can be fragmented and sent through the TLS tunnel.

3. The third option is to set the Maximum Segment Size (MSS) to 1460 as follows:

sysopt conn tcpmss 1460

In this case, the TLS MTU will be 1427 (RC4/SHA1) which is larger than the DTLS MTU 1418 (AES/SHA1/LZS). This should resolve the issue with TCP from the ASA to the AnyConnect client (thanks to MSS), but large UDP traffic from the ASA to the AnyConnect client might suffer from this as it will be dropped by the AnyConnect client due to the lower AnyConnect client MTU 1418. If sysopt conn tcpmss is modified, it might affect other features such as LAN-to-LAN (L2L) IPSec VPN tunnels.

If DTLS is not blocked in the middle another potential cause for the DTLS failure that DTLS is configured on a non-default port after the WebVPN is enabled (for example, when the webvpn enable outside command is entered). This is due to Cisco bug ID CSCuh61321 and has been seen in Release 9.x where the ASA pushes the non-default port to the client, but continues to listen to the default port. Consequently, the DTLS is not built and AnyConnect reconnects.

The workaround for this problem is:

  1. Disable the WebVPN.
  2. Enter the DTLS port.
  3. Enable the WebVPN.

Regards,

-Gustavo Medina


View solution in original post

9 Replies 9

gwes
Level 1
Level 1

Installed the latest Client 3.1.04059 but the problem is still there. I see the same issue on w7 and w8 clients. I'm suspecting the ASA firmware now.

This fixed me using ASA 9.1.1

no compression anyconnect-ssl http-comp

group-policy DfltGrpPolicy attributes

webvpn

  anyconnect mtu 1200

Shaoqin Li
Level 3
Level 3

the log is not sufficient

get more log from asa

Sent from Cisco Technical Support iPad App

gwes
Level 1
Level 1

I’ve been having this for a while now. But other problems kept me from further investigating this issue. It a nagging problem, but after the reconnect everything is ok. So because of that, this one was not so high in my list of issue’s to solve. I suspected this to be a client thing. I’ve seen the same problem on windows7 and windows8 clients. I don’t know exactly when this problem started, but after installing the latest client 3.1.0459 the problem was not fixed. By now I would assume that Cisco would have fixed this bug, so I now started to suspect the firmware or VPN configuration of our ASA. Which was running 9.1 software. I started by doing a:

# debug webvpn anyconnect 255

After looking at the logs something caught my eye

Group User < omitted > IP < omitted > Transmitting large packet 1418 (threshold 1331).

What the??? What is this? After using google, I found this document.

Error:− %ASA−6−722036: Group client−group User xxxx IP x.x.x.x Transmitting large packet 1220 (threshold 1206)
The %ASA−6−722036: Group < client−group > User < xxxx > IP < x.x.x.x>
Transmitting large packet 1220 (threshold 1206)
error message appears in the logs of
the ASA. What does this log mean and how is this resolved?
Solution:
This log message states that a large packet was sent to the client. The source of the packet is not aware of the
MTU of the client. This can also be due to compression of non−compressible data. The workaround is to turn
off the SVC compression with the svc compression none command. This resolves the issue.

After applying these rules to the group policy configuration my problem was gone

webvpn
   anyconnect mtu 1331
   anyconnect ssl compression none

http://www.cyu.nl/anyconnect-reconnects-after-1-minute/

lowering the MTU size was indeed the solution.

thx

Michael Tooma
Level 1
Level 1

I updated my ASA to 9.1.4 and the AnyConnect client to 3.1.05152 and I am no longer having reconnect issues.

Hello Michael,

The problem here is because we cannot succesfully establish a DTLS tunnel. This could happen because:

- DTLS is blocked somewhere in the path

- A non-default DTLS port is being used

If DTLS is blocked in the middle the issue is because as of ASA Release 9.x and AnyConnect Release 3.x, an optimization has been introduced in the form of distinct Maximum Transition Units (MTUs) that are negotiated for TLS/DTLS between the client/ASA. Previously, the client derived a rough estimate MTU which covered both TLS/DTLS and was obviously less than optimal. Now, the ASA computes the encapsulation overhead for both TLS/DTLS and derives the MTU values accordingly.

As long as DTLS is enabled, the client applies the DTLS MTU (in this case 1418) on the VPN adapter (which is enabled before the DTLS tunnel is established and is needed for routes/filters enforcement), to ensure optimum performance. If the DTLS tunnel cannot be established or it is dropped at some point, the client fails over to TLS and adjusts the MTU on the virtual adapter (VA) to the TLS MTU value (this requires a session level reconnect).

In order to eliminate this visible transition of DTLS > TLS,  you can configure a separate tunnel group for TLS only access for users that have trouble with the establishment of the DTLS tunnel (such as due to firewall restrictions).

1. The best option is to set the AnyConnect MTU value to be lower than the TLS MTU, which is then negotiated.

group-policy ac_users_group attributes

webvpn

  anyconnect mtu 1300

This makes TLS and DTLS MTU values equal. Reconnections are not seen in this case.

2. The second option is to allow fragmentation.

group-policy ac_users_group attributes

webvpn

  anyconnect ssl df-bit-ignore enable

With fragmentation, large packets (whose size exceeds the MTU value) can be fragmented and sent through the TLS tunnel.

3. The third option is to set the Maximum Segment Size (MSS) to 1460 as follows:

sysopt conn tcpmss 1460

In this case, the TLS MTU will be 1427 (RC4/SHA1) which is larger than the DTLS MTU 1418 (AES/SHA1/LZS). This should resolve the issue with TCP from the ASA to the AnyConnect client (thanks to MSS), but large UDP traffic from the ASA to the AnyConnect client might suffer from this as it will be dropped by the AnyConnect client due to the lower AnyConnect client MTU 1418. If sysopt conn tcpmss is modified, it might affect other features such as LAN-to-LAN (L2L) IPSec VPN tunnels.

If DTLS is not blocked in the middle another potential cause for the DTLS failure that DTLS is configured on a non-default port after the WebVPN is enabled (for example, when the webvpn enable outside command is entered). This is due to Cisco bug ID CSCuh61321 and has been seen in Release 9.x where the ASA pushes the non-default port to the client, but continues to listen to the default port. Consequently, the DTLS is not built and AnyConnect reconnects.

The workaround for this problem is:

  1. Disable the WebVPN.
  2. Enter the DTLS port.
  3. Enable the WebVPN.

Regards,

-Gustavo Medina


Hello,

 

We have an issue where clients connecting and shortly getting disconnected after around 1 minute however this is for users on protocol tslv1.2, anyone that is connected using DTLS works fine.  I am not sure what else i can try? 

we the command on our group policy "svc DTLS none" , not sure if this has anything to do with it? i have spent hours on this hoping someone can help solve! we are using anyconnect client version 4.4.04030, also we 8.0 ASA version.

 

here is DART log error.


Description : Function: CSocketTransport::callbackHandler
File: IPC\SocketTransport.cpp
Line: 1830
Invoked Function: ::WSARecv/::WSARecvFrom
Return Code: 10058 (0x0000274A)
Description: A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call.

Zero bytes transferred

 

thanks

 

Reduce the mtu value and test until you get a working value (don't drop it
too low)

group-policy test attributes
webvpn
anyconnect mtu 1380
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: