Keeping IPsec SA up

IPsec, L2TP, Split tunneling, PPTP and all other VPN related posts.
Post Reply

Keeping IPsec SA up

Post by Guest » Mon Dec 13, 2010 8:23 pm

Hello Community,


Customer has about 50 remote 871s homeworkers with IP phones.

Main site has ASA 5510 housing the CUCM.


Problem is...

When user1 calls user2 theres no audio (since theres no IPsec SA built between remote users).

The fact that user1 calls user2 builts the IPsec between router1 and ASA, but since theres no IPsec SA for the users between router2 and ASA, the audio fails.


If user2 calls user1 now, then the call is succesful, because the SAs are built:

IPsec SA between router1 and ASA for the user1-user2 traffic

IPsec SA between router2 and ASA for the user2-user1 traffic


So, the problem is that both sides have to initiate traffic to make this work.


What I did to fix the problem is configure IP SLA on the routers to send a PING packet every 10 minutes to their peer homeworkers (thus keeping the SAs between remote locations up all the time).

IP SLA works but Im looking for a better way to fix the problem of having to manually initiate traffic (DMVPN or running a routing protocol does not work with ASA through the tunnel).


I guess increasing the IPsec SA lifetime is another option.


Just looking for recommendations, thanks!




Re:Keeping IPsec SA up

Post by Guest » Mon Dec 13, 2010 8:49 pm

Hi Federico,


Have you considered configuring EzVPN/Easy VPN, with ASA as EzVPN server and Clients (Routers/ASA5505) as EzVPN clients? This would create the tunnel as soon as it is configured.


Also, apart from increasing the lifetime of the SA (which is basically delaying phase-2 rekey), you might want to configure vpn-idle-timeout to be "none" under ASAs group-policy.


Any Thoughts?





Re:Keeping IPsec SA up

Post by Guest » Mon Dec 13, 2010 8:55 pm

Thank you Praveena for your answer.

I think that you e correct but the problem that I still see, is that the tunnel is actually up all the time.

The IPsec SA between the homeworker and the ASA (where the CUCM resides) is always up (the IP phone never deregisters).


The IPsec SA that is not always up is the one that goes from user1 LAN to user2 LAN (through the ASA).


So, if I configure EzVPN, then I need to make sure that traffic is initialized from both ends to the the other homeworker in order to bring the appropiate SA up as well.


Another solution I was thinking is to map all remote LANs in a single ACL statement allowing that SA to be up (but the IP scheme is not really contiguous).


I really appreciate your interest and help on this one, please let me know if Im wrong in my assumption.

Thank you!




Re:Keeping IPsec SA up

Post by Guest » Mon Dec 13, 2010 9:31 pm

Lets say we have homeworker1 and homeworker2

In order for homeworker1 to have an IPsec SA up for traffic to homeworker2, homeworker1 must have to initiate traffic.

In order for homeworker2 to have an IPsec SA up for traffic to homeworker1, homeworker2 must have to initiate traffic.


The problem is that homeworker1 cannot call homeworker2 (or viceversa) if theres no traffic being sent in the opposite direction to bring the corresponding IPsec SA up.

The only reason for the IPsec SA to be build is when a homeworker calls another (theres only an IP phone and a computer on each remote site).


This behavior does not change if having a dynamic Site-to-Site or EzVPN.


I have tested several times now and with IP SLA works great. I guess I will stick to that.




Re:Keeping IPsec SA up

Post by Guest » Mon Dec 13, 2010 10:39 pm

Hi Federico,


sorry for the late response - I thought I had posted this already but I just noticed I had not. I thought Id still let you know my thoughts anyway...


I guess it depends on whether you use split tunneling or not. If not then there should only be a single SA pair (between and spoke-LAN, or between and assigned IP if not doing NEM).


If doing split tunneling, and if the hub has a static crypto map per peer then Id still expect the hub to initiate the new SA.


If doing split tunneling and dynamic crypto map, I suppose migrating it to DVTI might be a solution.


Of course if you e happy with the current solution of using SLA, then
ever change a winning team applies 




PS: congrats with your VIP status!

Post Reply