Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
20096
Views
5
Helpful
4
Replies

Problem with SSL AnyConnect dropping connection after 5-10 minutes

baskervi
Level 1
Level 1

‎07-24-2015 09:44 AM - edited ‎02-21-2020 08:21 PM

We have an IPSec site-to-site VPN created between an ASA-5510 running 8.2(5) and a PIX-515 running 7.2(4), and on the network with the ASA, we have a vendor that requires us to SSL VPN into their ASA-5505. The users on the remote site (PIX end) therefore have to traverse the IPSec VPN tunnel to connect with SSL AnyConnect client, and there is no problem connecting, but the connection drops after just a few minutes. This vendor also doesn't allow AnyConnect clients to connect from the Internet, so the remote users have to traverse the IPSec tunnel to connect to the ASA-5505. We don't have problems with users within our company access resources on either end of the IPSec VPN tunnel.

We haven't made any changes to firmware versions on any of the firewalls nor to any of their configurations, but it was working fine until about a week ago. We've rebooted the ASA-5505 and PIX-515, but we'll have to schedule a reboot of the ASA-5510.

We've also done a continuous ping (using ping -l 1200 -f -t 172.16.3.3, which is the ASA-5505 address) across the IPSec VPN tunnel for 30 minutes, and we only had 2 dropped packets. Connectivity appears to be solid. We are monitoring bandwidth, and for a 30 second interval, the average is under 50% the available bandwidth, which isn't saying we don't peak around the max at any point in time. Also, we can connect to the SSL VPN with our local network, and the connection never drops.

Here is some relevant information from the logs - the only thing that I can make of the following is that the AnyConnect connection appears to be dropping. Hopefully, someone else can make some sense about this. 

6|Jul 22 2015|14:48:48|725001|172.17.9.54|49393|||Starting SSL handshake with client outside:172.17.9.54/49393 for DTLSv1 session.
6|Jul 22 2015|14:48:48|725001|172.17.9.54|49393|||Starting SSL handshake with client outside:172.17.9.54/49393 for DTLSv1 session.
4|Jul 22 2015|14:48:44|711004|||||Task ran for 292 msec, Process = Dispatch Unit, PC = 829be8c, Call stack =   0x0829be8c  0x0806a25c
4|Jul 22 2015|14:48:44|711004|||||Task ran for 292 msec, Process = Dispatch Unit, PC = 829be8c, Call stack =
4|Jul 22 2015|14:48:43|722051|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> IPv4 Address <172.16.17.240> IPv6 address <::> assigned to session
6|Jul 22 2015|14:48:43|716059|||||Group <VendorSSLVPN> User <first.last> IP <172.17.9.54> AnyConnect session resumed connection from IP <172.17.9.54>.
6|Jul 22 2015|14:48:43|722022|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> TCP SVC connection established without compression
5|Jul 22 2015|14:48:43|722034|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> New TCP SVC connection, no existing connection.
6|Jul 22 2015|14:48:43|725002|172.17.9.54|58588|||Device completed SSL handshake with client outside:172.17.9.54/58588
6|Jul 22 2015|14:48:42|725001|172.17.9.54|58588|||Starting SSL handshake with client outside:172.17.9.54/58588 for TLSv1 session.
6|Jul 22 2015|14:48:42|725007|172.17.9.54|58540|||SSL session with client outside:172.17.9.54/58540 terminated.
6|Jul 22 2015|14:48:42|722023|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> TCP SVC connection terminated without compression
6|Jul 22 2015|14:48:42|725007|172.17.9.54|60846|||SSL session with client outside:172.17.9.54/60846 terminated.
6|Jul 22 2015|14:48:42|722023|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> UDP SVC connection terminated without compression
6|Jul 22 2015|14:48:42|716058|||||Group <VendorSSLVPN> User <first.last> IP <172.17.9.54> AnyConnect session lost connection. Waiting to resume.
5|Jul 22 2015|14:48:42|722037|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> SVC closing connection: Transport closing.
5|Jul 22 2015|14:48:42|722010|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> SVC Message: 17/ERROR: Reconnecting to recover from error..
6|Jul 22 2015|14:48:41|302303|172.16.17.240|58582|172.22.0.20|1433|Built TCP state-bypass connection 125954 from outside:172.16.17.240/58582 (172.16.17.240/58582)(LOCAL\first.last) to inside:172.22.0.20/1433 (172.22.0.20 /1433)
6|Jul 22 2015|14:48:36|110002|172.16.17.240|60851|||Failed to locate egress interface for UDP from outside:172.16.17.240/60851 to 239.255.255.250/1900
6|Jul 22 2015|14:48:35|722022|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> UDP SVC connection established without compression
5|Jul 22 2015|14:48:35|722033|||||Group <GroupPolicy_VendorSSLVPN> User <first.last> IP <172.17.9.54> First UDP SVC connection established for SVC session.
6|Jul 22 2015|14:48:35|725002|172.17.9.54|60846|||Device completed SSL handshake with client outside:172.17.9.54/60846
6|Jul 22 2015|14:48:34|725003|172.17.9.54|60846|||SSL client outside:172.17.9.54/60846 request to resume previous session.

<repeats back over from the top>

 

Thanks for your help.

4 people had this problem
Labels:
0 Helpful
4 Replies 4

Dinesh Moudgil
Cisco Employee
Cisco Employee

‎07-25-2015 07:43 AM


Couple of things to ponder :-
* Whats the error message you get on the client?
* Is it happening on specific systems or all the users.
* Might as well share the webvpn,tunnel-group and group-policy configuration.
* DART logs at the time of issue will give the client side information as to why 
  connection is lost.

Looking at the errors,"AnyConnect session lost connection. Waiting to resume" , it means that if the endpoint is not responsive, the ASA tears down the tunnel in the session database, and moves the session into a "Waiting to Resume" mode i.e ASA no longer communicates with the client.

Try enabling keepalives under group-policy ("command : anyconnect ssl keepalive" under group-policy) if you haven't.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.


 

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/
0 Helpful

baskervi
Level 1
Level 1
In response to Dinesh Moudgil

‎07-27-2015 07:46 AM

Dinesh, thank you very much for your input.

I'll have to get with the users today regarding the error messages and logs on their workstations.

It only happens to workstations that traverse the IPSec tunnel. All other connections work just fine. Because this was impacting a vendor's system, we were given permission to open the AnyConnect traffic to our remote location's public IP address, and the AnyConnect client is stable and has no disconnects. The vendor would like to close this back down. The problem occurs on all Win7 and Win7 workstations across the IPSec tunnel.

I've attached the pertinent configuration of the firewall.

I understand it looks like a connectivity issue, but a continuous ping drops practically no packets. We ran one for 30 minutes and had two dropped packets and another one for 15 minutes with no dropped packets. The IPSec tunnel is used constantly for users to get email and files at the host location, and there haven't been any connectivity issues there. It may be that our main ASA-5510 needs a reboot, and that's been scheduled.

We'll work with the vendor for enabling the keepalive command.

Preview file
8 KB
0 Helpful

Dinesh Moudgil
Cisco Employee
Cisco Employee
In response to baskervi

‎07-27-2015 08:34 PM

There are couple of tunnel-group and  group policies in the config snippet. Please point which one the clients are using and sharing DART logs will surely help to see why we see this behaviour.


Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/
0 Helpful

ciscoprolin
Level 1
Level 1
In response to Dinesh Moudgil

‎02-08-2016 03:01 AM

Hi Dinesh,

we are facing the same issue. Our customer is connected via AnyConnect VPN and suddenly he gts kicked out of the SAP session with the message:

WSAECONNRESET

(10054)

Connection reset by peer.

A existing connection was forcibly closed by the remote host.

At that time he's also unable to ping the System or any other System.

The ASA Log Shows that there are stale SVC Connections and a few minutes later there is a request to resume previous session:

5|Feb 05 2016|13:43:08|722028|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> Stale SVC connection closed.
5|Feb 05 2016|13:43:08|722028|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> Stale SVC connection closed.
6|Feb 05 2016|13:43:08|725007|194.230.159.117|30815|||SSL session with client outside:194.230.159.117/30815 terminated.
6|Feb 05 2016|13:43:08|725007|194.230.159.117|30815|||SSL session with client outside:194.230.159.117/30815 terminated.
6|Feb 05 2016|13:43:08|722022|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> UDP SVC connection established without compression
6|Feb 05 2016|13:43:08|722022|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> UDP SVC connection established without compression
5|Feb 05 2016|13:43:08|722032|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> New UDP SVC connection replacing old connection.
5|Feb 05 2016|13:43:08|722032|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> New UDP SVC connection replacing old connection.
6|Feb 05 2016|13:43:08|725002|194.230.159.117|30814|||Device completed SSL handshake with client outside:194.230.159.117/30814
6|Feb 05 2016|13:43:08|725002|194.230.159.117|30814|||Device completed SSL handshake with client outside:194.230.159.117/30814
6|Feb 05 2016|13:43:08|725003|194.230.159.117|30814|||SSL client outside:194.230.159.117/30814 request to resume previous session.
6|Feb 05 2016|13:43:08|725003|194.230.159.117|30814|||SSL client outside:194.230.159.117/30814 request to resume previous session.
6|Feb 05 2016|13:43:08|725001|194.230.159.117|30814|||Starting SSL handshake with client outside:194.230.159.117/30814 for DTLSv1 session.
6|Feb 05 2016|13:43:08|725001|194.230.159.117|30814|||Starting SSL handshake with client outside:194.230.159.117/30814 for DTLSv1 session.
6|Feb 05 2016|13:43:08|725001|194.230.159.117|30814|||Starting SSL handshake with client outside:194.230.159.117/30814 for DTLSv1 session.
6|Feb 05 2016|13:43:08|725001|194.230.159.117|30814|||Starting SSL handshake with client outside:194.230.159.117/30814 for DTLSv1 session.
6|Feb 05 2016|13:42:33|110003|131.220.5.244|0|131.220.220.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:42:33|110003|131.220.5.244|0|131.220.220.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:40:32|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:40:32|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:39:42|302010|||||44 in use, 554 most used
6|Feb 05 2016|13:39:42|302010|||||44 in use, 554 most used
6|Feb 05 2016|13:38:32|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:38:32|110003|131.220.5.244|0|131.2202.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:37:33|110002|131.220.29.32|59811|||Failed to locate egress interface for UDP from outside:131.220.29.32/59811 to 239.255.255.250/1900
6|Feb 05 2016|13:37:33|110002|131.220.29.32|59811|||Failed to locate egress interface for UDP from outside:131.220.29.32/59811 to 239.255.255.250/1900
6|Feb 05 2016|13:37:21|110002|131.220.29.32|59811|||Failed to locate egress interface for UDP from outside:131.220.29.32/59811 to 239.255.255.250/1900
6|Feb 05 2016|13:37:21|110002|131.220.29.32|59811|||Failed to locate egress interface for UDP from outside:131.220.29.32/59811 to 239.255.255.250/1900
6|Feb 05 2016|13:36:33|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:36:33|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:34:32|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
6|Feb 05 2016|13:34:32|110003|131.220.5.244|0|131.220.2.34|0|Routing failed to locate next hop for icmp from outside:131.220.5.244/0 to outside:131.220.2.34/0
5|Feb 05 2016|13:33:16|722028|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> Stale SVC connection closed.
5|Feb 05 2016|13:33:16|722028|||||Group <UniBonn-Urzextern> User <smith> IP <194.230.159.117> Stale SVC connection closed.
6|Feb 05 2016|13:33:16|725007|194.230.159.117|30816|||SSL session with client outside:194.230.159.117/30816 terminated.
6|Feb 05 2016|13:33:16|725007|194.230.159.117|30816|||SSL session with client outside:194.230.159.117/30816 terminated.

Thanks in advance,

Thorsten

Customers Also Viewed These Support Documents