Keeping IPsec SA up

[Federico Coto Fajardo]

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 there's no audio (since there's no IPsec SA built between remote users).

The fact that user1 calls user2 builts the IPsec between router1 and ASA, but since there's 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 I'm 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!

Federico.

[Praveena Shanubhogue · Accepted solution]

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 ASA's group-policy.

Any Thoughts?

Regards,

Praveen

[Federico Coto Fajardo]

Thank you Praveena for your answer.

I think that you're 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 I'm wrong in my assumption.

Thank you!

Federico.

[Federico Coto Fajardo]

Let's 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 there's 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 (there's 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.

Federico.

[Herbert Baerten · Accepted solution]

Hi Federico,

sorry for the late response - I thought I had posted this already but I just noticed I had not. I thought I'd 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 0.0.0.0 and spoke-LAN, or between 0.0.0.0 and assigned IP if not doing NEM).

If doing split tunneling, and if the hub has a static crypto map per peer then I'd 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're happy with the current solution of using SLA, then 'never change a winning team' applies 

cheers

Herbert

PS: congrats with your VIP status!

[Federico Coto Fajardo]

Herbert,

You're right using split-tunneling.

If i can summarize all traffic in a single ACL it will fix the problem (because that IPsec SA will always be up).

But because of the IP scheme, there are separate ACLs for each client.

--------SA to Client2

---SA-to-hub

Client1 --- ASA --- Client2

              SA to hub----

        SA to Client1------

Each client has an always up established IPsec SA to the ASA (maintained by the IP phones and CUCM).

Problem is that the IPsec SA to the remote client is only established when the client sends traffic to its peer.

So, if client1 calls client2 it won't work unless client2 initiates traffic back to client1 as well.

Problem with DVTI is that the hub is an ASA (not IOS).

I did the IP SLA which I doubt is a best practice to fix this but it's working for now :-)

Thank you!

Federico.