cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4221
Views
0
Helpful
6
Replies

302014: Teardown TCP connection - Tunnel has been torn down

mdeguerre
Level 1
Level 1

Rather than retyping everything, I'll just say I'm seeing the same problem as mtrcek is describing here: http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Expert%20Archive&topic=Security&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dddcf1a/96#selected_message

Intermittent sessions being dropped across a lan-to-lan IPSec tunnel.

An example "hit":

07:53:27: %PIX-7-609001: Built local-host inside:1.1.1.1

07:53:27: %PIX-6-305011: Built dynamic TCP translation from inside:1.1.1.1/1322 to outside:2.2.2.2/5983

07:53:27: %PIX-6-302013: Built outbound TCP connection 211874 for outside:3.3.3.3/23 (3.3.3.3/23) to inside:1.1.1.1/1322 (2.2.2.2/5983)

07:59:42: %PIX-6-305011: Built dynamic TCP translation from inside:1.1.1.1/1334 to outside:2.2.2.2/6001

07:59:42: %PIX-6-302013: Built outbound TCP connection 212825 for outside:3.3.3.3/4001 (3.3.3.3/4001) to inside:1.1.1.1/1334 (2.2.2.2/6001)

08:37:46: %PIX-6-302014: Teardown TCP connection 212825 for outside:3.3.3.3/4001 to inside:1.1.1.1/1334 duration 0:38:02 bytes 287688 Tunnel has been torn down

08:37:46: %PIX-6-106015: Deny TCP (no connection) from 1.1.1.1/1334 to 3.3.3.3/4001 flags PSH ACK on interface inside

08:37:46: %PIX-6-106015: Deny TCP (no connection) from 1.1.1.1/1334 to 3.3.3.3/4001 flags PSH ACK on interface inside

08:37:46: %PIX-6-106015: Deny TCP (no connection) from 1.1.1.1/1334 to 3.3.3.3/4001 flags PSH ACK on interface inside

08:37:46: %PIX-6-302014: Teardown TCP connection 211874 for outside:3.3.3.3/23 to inside:1.1.1.1/1322 duration 0:44:17 bytes 2156 Tunnel has been torn down

08:38:01: %PIX-6-305012: Teardown dynamic TCP translation from inside:1.1.1.1/1322 to outside:2.2.2.2/5983 duration 0:44:32

08:38:16: %PIX-6-305012: Teardown dynamic TCP translation from inside:1.1.1.1/1334 to outside:2.2.2.2/6001 duration 0:38:32

08:38:16: %PIX-7-609002: Teardown local-host inside:1.1.1.1 duration 0:44:47

The unexplainable "Tunnel has been torn down" logs coincide with bouts of user complaints. There's no indication that the tunnel is actually going down or being rekey'd. And before migrating from 6.3 to 7.2 life was good (and since we rolled back to 6.3 because of this problem life has been good too - can't stay at 6 forever though).

TAC's telling me not to use PAT towards the IPSec tunnel suggesting a nat-0 or static instead, which isn't really an option I'm afraid.

Anyone else bump into something similar?

6 Replies 6

I've got exactly the same issue at a customer of mine, it seems to hit vpns between pix 7.x releases (tried several, including 7.22) and at least 1812 ios 12.4.(9)T2.

It seems that during ipsec rekeying pix closes all connections with outside addresses linked to that tunnel.

The funny thing is that I've shortened the rekeyng time in order to speed up the tests, at 600 seconds and 3600 seconds (the default) the issue shows up almost on each rekey, at 120 seconds (the minimum) the issue seems to disappear!!!

With another 1812 or an asa (7.22 release) at the other end in place of the pix the issue seems to disappear also.

Tried also to create a new vpn from the same pix and a second 1812 with 12.4.(9)T11 release and the issue doesn't shows up, but that's another environment.

Now I'm shipping a new 1812 with the latest release at the customer site and see what happens.

Thanks for the tip on the timings - I'll have to fiddle with that when I (finally) get the chance to retest.

And ...

CSCsi40796

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi40796

Good to see that Cisco has recognized the issue, although it seems not quite the same as the one I've experienced.

Based on my limited testing, I came to the conclusion that my bug seems to affect all 7.x releses on pix only, not asa.

It seems to happen at rekeing time

It seems to be influenced by the value of the rekeying time configured.

Bye,

Max.

Has Cisco offered a work around or interim release for this specific problem yet?

Nope.

Though the testing I've been able to do shows that my headaches really are, as the message implies, because the tunnel was torn down (and immediately rebuilt).

- The tunnel goes down in flames on each phase1 rekey.

- New traffic comes along and a new tunnel is built just fine.

- The original connection is put to use in some fashion and *poof*... the conn is torn down with that err.

Been chasing that same error for quite some time now. The next interim release should be out pretty soon so let's see if they have a fix by then.

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: