03-28-2007 10:01 AM - edited 03-11-2019 02:53 AM
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?
04-13-2007 12:48 AM
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.
04-23-2007 05:42 AM
Thanks for the tip on the timings - I'll have to fiddle with that when I (finally) get the chance to retest.
And ...
CSCsi40796
04-23-2007 06:25 AM
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.
05-08-2007 11:06 AM
Has Cisco offered a work around or interim release for this specific problem yet?
05-08-2007 11:15 AM
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.
05-08-2007 11:25 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide