ASA Site-to-Site VPN stops when Traffic Volume rekey reached

Unanswered Question
Jan 13th, 2010

Greetings all,

We have several site-to-site IPSec VPN's setup.

All are running on ASA's 8.2(1).

All have a Security Association Lifetime (Time) of 8 hours.

All have a Security Association Lifetime (Traffic Volum) of 4608000 KiloBytes.

We have an issue when we do Oracle logshipping between the sites.

This triggers the Traffic Volume rekey as can be seen by this entry in the logs: -

%ASA-7-702307: IPSEC: An inbound L2L SA (SPI= 0x169FA1C1) between <Site A IP> and <Site B IP> (user= <Site B IP>) is rekeying due to data rollover.

However it does not appear as if the renegotiation is occurring properly.  Within 10 to 15 minutes data stops being transmitted along the link, even though the IPSec tunnel still appears up in the ASDM GUI.

The 'fix' for this is that we are using is to login to the ASDM GUI and bounce the link by going to Monitoring => VPN => VPN Statistics => Sessions => IPSec Site-to-Site.  Then select the appropriate VPN tunnel and click on 'Logout'.  This forces a link renegotiation which works fine.

I have attached a logfile from the local ASA (there's nothing in the logfile of the remote ASA until we bounce the VPN tunnel).

Any help would be appreciated.

Regards,

Glenn Crawford.

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
hdashnau Wed, 01/13/2010 - 17:40

-Does other traffic over the tunnel work, like a ping at the same time this oracle traffic is failing? Traffic to other subnets over the vpn? Traffic to other tunnels?

-Does the tunnel show as up on both ASAs or just one - do a "show cry isa sa" and "show cry ipsec sa" and check to see if encaps and decaps are still incrementing on either side?

-Gather "debug cry isa 127" and "debug cry ipsec 127" on both sides to see if anything looks out of whack. To know if its out of whack compare this debug to a set of debugs from a working rekey -- you could just lower the time lifetime down to 10 minutes or so and bring up the tunnel again to get it to rekey more often -- at about 80% the total configured)

-heather

wotifadmin Wed, 01/13/2010 - 18:27

Thanks Heather.

In answer to your question(s): -

  • -Does other traffic over the tunnel work, like a ping at the same time this oracle traffic is failing? Traffic to other subnets over the vpn? Traffic to other tunnels?

Ping's fail, it's not just oracle traffic failing - it's all traffic including to other subnets over the vpn.  The other site-to-site VPN tunnels are unaffected.

  • -Does the tunnel show as up on both ASAs or just one - do a "show cry isa sa" and "show cry ipsec sa" and check to see if encaps and decaps are still incrementing on either side?

The tunnel shows up on both ASA's.  When we test it in a controlled fashion next time I will try the commands you suggested above to answer your questions about the encaps / decaps incrementing.

  • -Gather "debug cry isa 127" and "debug cry ipsec 127" on both sides to see if anything looks out of whack. To know if its out of whack compare this debug to a set of debugs from a working rekey -- you could just lower the time lifetime down to 10 minutes or so and bring up the tunnel again to get it to rekey more often -- at about 80% the total configured)

Thanks, will gather that information and post it here.  Need to wait for a maintenance window though {:?\

Regards,

Glenn Crawford.

Scott Hamill Thu, 05/05/2016 - 12:03

I have had the same problem for DAYS and the following command fixed the disconnects completely:

sysopt connection preserve-vpn-flows

andysuggars Wed, 08/24/2011 - 17:10

Hi Guys,

I'd like to know if this was resolved too because I'm having the same or similar problem

L2L vpn is up, stays up but one source subnet stops passing traffic over the vpn, while the other source subnets still work to the same hosts. Doing a "logout" for that SA as the OP mentioned he did fixes the problem for a while. There is no specific time limit, some days it is bad and happens often, other days it doesn't happen at all.

Cheers,

Andy

bascheew Thu, 04/26/2012 - 06:52

I have a customer that is having the same problem.  Anyone having any luck in resolving this?  I just raised the the traffic volume to as high as the field will allow (2147483647 KBytes) and we'll see how long that lasts!

andysuggars Sun, 04/29/2012 - 17:25

My issue sounded similar, an ASA VPN to a client 's Sonic Wall carried multiple SA's, the subnets associated with 2 SA's would stop routing and we lost connectivity, however the VPN was up and we could reach other subnets.

It was resolved by making sure that the "interesting traffic" in the phase 2 matched exactly on each end. It seems to have resolved the issue as the VPN has been stable every since. So check both configs at each end do match exactly the same. Make sure the routes to these networks are also correct at each end.

Cheers,

Andrew

gdawodu Thu, 04/26/2012 - 19:59

You might be hitting the bug CSCtq57752 on ASA

You have the option to disable volume based rekey (IOS 15.0(1) M and above). Since, volume based rekey cannot be disable  on ASA, setting it to max value and make time base rekey a low value might be helpful . Setting an appropriate low time based rekey value might be tricky. If you push a high volume data within that seconds specified, this will not solve the problem.You need to limit the amount of data that can be send.Also, If the time based value is set too low, rekey will happen so often and will put load on the  ASA

WEERAKOO69BA Sun, 05/20/2012 - 00:11

Hi,

I have a similar kind of requirement on ASA 5520{version 8.0(4)}.need to enable access via  ipsec vpn during a specific time like 10am to 3 pm.is there any way to do this??

Thanks a lot

domindiag1 Thu, 11/07/2013 - 07:59

I am having a similar problem.   I have a site to site tunnel with 3 subnets involved, 2 are clients access a server on the other side and one is a number of servers communicating to a server ( same one actually ) on the other end.   A clear ipsec sa peer x.x.x.x fixes the issue with tunnel not responding.....When it does happen, all data shows tunnel is up and when you try to ping a server on the other end....nothing.   Once tunnel reset, it appears to take about 4 days before it happens again.   New connections are not allowed, existing connections usually get disconnected within 15 minutes.   Defaults are set for rekey.   Any one find the solution other than what is mentioned above since I am unable to ping any subnet through the tunnel?  Is this still a possible rekey issue for me as well?

Actions

This Discussion