SAS application timeout

Unanswered Question
Apr 15th, 2009

Hopefully someone can help me out with this issue that has been going on for about 4 months now. I have a user that runs a SAS application over a l2l vpn tunnel that will crunch numbers for a long period of time, finally generating the data results after that period. This period can be anywhere from an hour to 12 hours, but there is no tcp chatter during this time. I am terminating the l2l vpn tunnel on an ASA 5520 running asa 8.04, and have noticed on the asa logs that the eventual return ACK packets are being denied because the connection has been torn down. I have tried increase the connection timeout values, but that has not changed behavior. I have also issued the command:

sysopt connection permit-vpn, but the command appears to have been deprecated, because it fails to show up in the running config.


Here are a couple lines from the log:

Apr 14 15:41:43 10.50.1.100 Apr 14 2009 15:41:43 10.50.1.100 : %ASA-6-302014: Teardown TCP connection 1647837 for Outside:10.2.5.85/8562 to Inside:10.50.162.123/3826 duration 0:09:31 bytes 148201 TCP Reset-I

Apr 15 04:41:53 10.50.1.100 Apr 15 2009 04:41:53 10.50.1.100 : %ASA-6-302014: Teardown TCP connection 1633014 for Outside:10.2.5.85/8562 to Inside:10.50.162.123/3444 duration 15:56:24 bytes 1415523 Tunnel has been torn down

Apr 15 04:41:54 10.50.1.100 Apr 15 2009 04:41:53 10.50.1.100 : %ASA-6-106015: Deny TCP (no connection) from 10.2.5.85/8562 to 10.50.162.123/3444 flags ACK on interface Outside

Apr 15 04:41:54 10.50.1.100 Apr 15 2009 04:41:54 10.50.1.100 : %ASA-6-106015: Deny TCP (no connection) from 10.2.5.85/8562 to 10.50.162.123/3444 flags ACK on interface Outside

Apr 15 04:41:55 10.50.1.100 Apr 15 2009 04:41:55 10.50.1.100 : %ASA-6-106015: Deny TCP (no connection) from 10.2.5.85/8562 to 10.50.162.123/3444 flags ACK on interface Outside

Apr 15 04:41:57 10.50.1.100 Apr 15 2009 04:41:57 10.50.1.100 : %ASA-6-106015: Deny TCP (no connection) from 10.2.5.85/8562 to 10.50.162.123/3444 flags ACK on interface Outside

Apr 15 08:42:34 10.50.1.100 Apr 15 2009 08:42:34 10.50.1.100 : %ASA-6-106015: Deny TCP (no connection) from 10.50.162.123/3444 to 10.2.5.85/8562 flags PSH ACK on interface Inside


Any help or ideas would be greatly appreciated. Thanks!


Ryan

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
acomiskey Wed, 04/15/2009 - 10:49

This may help....


BugID: CSCsj40681


ENH: PIX/ASA: Maintain TCP connections when VPN tunnels flap

This is an enhancement request to prevent disruption of TCP connections over IPsec tunnel when IPsec tunnel is dropped and reestablished by any reason (even for very short time).


Symptom:


With PIX/ASA 7.x and 8.x, when IPSec VPN tunnel flaps briefly, all TCP connections previously established over this tunnel are dropped too. This is disruptive for many TCP applications.


This happens by design in PIX 7.x and 8.x. This issue does not occur on other platforms: PIX 6.x, IOS, VPN3000.


Example of Syslog message generated on PIX/ASA:


%ASA-6-302014: Teardown TCP connection 57983 for outside:192.168.0.100/80 to inside:10.0.0.100/1135 duration 0:00:36 bytes 53947 Tunnel has been torn down


Note a TCP drop reason of "Tunnel has been torn down". Level 6 logging must be enabled to see this message.


Condition:


- Issue most often start to occur after migrating tunnels from not affected platforms (IOS, PIX 6.x or VPN3K) to PIX/ASA 7.x/8.x


- To trigger that issue, IPsec tunnels should be bouncing periodically and TCP sessions should be active this time. It is usually observed when IPsec lifetime or idle time is less than TCP session idle timeout, and there are long periods of no activity over TCP sessions.


- This problem may happen especially often in case of LAN-to-LAN IPsec tunnel between PIX 7/8 and Microsoft Windows 2000/2003 (or ISA Server 2000/2004) because on Microsoft platforms IPsec has 5 (!) minutes idle timer by default. In this scenario tunnels can flap every 5 minutes, causing TCP drops.


Workaround:


Increase IPsec idle timers and/or lifetimes on both crypto peers. It is generally enough to have IPsec idle timers/lifetimes bigger than TCP session idle timeout.


In case of IPsec L2L tunnel to Microsoft platform, IPsec idle timer on Microsoft side may be increased from 5 min to 1 hour via Registry. This will make tunnels bouncing less often (or even not bouncing at all):


http://support.microsoft.com/kb/257225

http://support.microsoft.com/kb/917025


Further Problem Description


This enhancement request was eventually resolved by adding new CLI: 'sysopt connection preserve-vpn-flows'. If both crypto peers are PIX 7/8, this command (available in fixed software versions) should be enabled on both ends of the tunnel before the tunnel comes up. If one crypto peer is PIX/ASA 7/8 but another one is some not affected device, then it's enough to enable this command on PIX 7/8 only.


If the command is enabled when the tunnels were already active, the tunnels should be cleared and reestablished to take effect.


If the command is not enabled, then loading fixed software will have no effect


Actions

This Discussion