Redundat VPN

[david-lima]

Hi all, I have 2 ASA's 5510 in the central office and each one has its own internet connection with different ISP. In the remote site I have 1 ASA 5505. I already have a VPN connection with the first ASA to tha central office, I would like to have a redundant VPN connection to the second ASA in case of hardware or ISP failure.

I read that I can configure multiple peers in the remote ASA if it is configured with connection type originate-only, but when I apply this configuration VPN connection goes down. I guess I missing something in this configuration.

Thanks a lot guys.

David

Central Office ASA 1 and ASA 2 config has the same configuration

crypto map promujer 30 match address vpnsre

crypto map promujer 30 set pfs

crypto map promujer 30 set peer IP-Remote ASA

crypto map promujer 30 set transform-set ESP-3DES-MD5

crypto isakmp policy 1

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

tunnel-group IP-RemoteASA  type ipsec-l2l

tunnel-group IP-RemoteASA ipsec-attributes

pre-shared-key *

Remote Office

crypto map promujer 70 set connection-type originate-only

crypto map promujer 70 match address vpnsre

crypto map promujer 70 set pfs

crypto map promujer 70 set peer IP-Central-ASA1 IP-Central-ASA2

crypto map promujer 70 set transform-set ESP-3DES-MD5

crypto isakmp policy 1

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

tunnel-group IP-Central-ASA1  type ipsec-l2l

tunnel-group IP-Central-ASA1 ipsec-attributes

pre-shared-key *

tunnel-group IP-Central-ASA2  type ipsec-l2l

tunnel-group IP-Central-ASA2 ipsec-attributes

pre-shared-key *

[raga.fusionet]

David, the tunnel will go down becuase you are changing the crypto map settings, now remember that you are changing it to originate only on the remote site. We are you trying to initiate traffic from?

What's the output of the show crypto isa sa after you try to initiate traffic from the remote site?

[david-lima]

Hi Luis Diego, thanks for your response. I was wrong. The Central ASA's needs to be configured as answer-only and the remote ASA as origiate-only.

But I have one issue with this configuration, only the VPN is UP with the first peer in the list, It doesn't try to negotiate with the redundant peer when the primary link goes down.

I guess I'm missing something.

Please check the relevant configuration.

The actual configuration looks like this:

Remote Peer

crypto map promujer 10 match address vpnlpz

crypto map promujer 10 set pfs

crypto map promujer 10 set connection-type originate-only

crypto map promujer 10 set peer IPASACentral-1IPASACentral-2

crypto map promujer 10 set transform-set ESP-3DES-MD5

tunnel-group DefaultRAGroup ipsec-attributes

isakmp keepalive threshold 10 retry 2

tunnel-group IPASACentral-1 type ipsec-l2l

tunnel-group IPASACentral-1 ipsec-attributes

pre-shared-key *

tunnel-group IPASACentral-2 type ipsec-l2l

tunnel-group IPASACentral-2 ipsec-attributes

pre-shared-key *

The Central ASAs have the same crypto map configuration to the remote ASA

crypto map promujer 30 match address vpnsre

crypto map promujer 30 set pfs

crypto map promujer 30 set peer RemoteASA

crypto map promujer 30 set transform-set ESP-3DES-MD5

[raga.fusionet]

When you say "It doesn't try to negotiate with the redundant peer when the primary link goes down." How are you testing the secondary connection? I mean, you have the tunnel up with primary peer, then take primary link down and then wait for remote site to reestablish a connection with secondary peer?

If that is the case what happens if you:

1. Create the tunnel to the primary peer

2. Take the primary peer link down

3. Clear the tunnel on the remote site by issuing a "clear crypto isa sa" and "clear crypto ipsec sa".

4. Try to re establish the tunnel (it should try the primary peer and then the secondary peer)

If that works then all you need to do is enable isakmp keepalives so that the remote site "realizes" that the primary peer is down:

crypto isakmp keepalive 10 3

Give it a try and let me know how it goes.

[david-lima]

Hi Luis Diego, thanks a lot for your help. It's working fine, just one question. When the Central ASA1 with the primary internet line goes down, the VPN tunnel goes UP between the Central ASA2 and the Remote ASA, but when the Central ASA1 internet line goes UP again, the VPN tunnel remains acttive with the second Central ASA2.

If I do "clear cry isa sa" in the remote ASA, the VPN tunnel go back with the Central ASA 1 again.

Is there a way to make that when the primary Central ASA1 is UP, the VPN tunnel is formed between the remote ASA and the Central ASA1 again?

It's hard because I have like 20 remote sites.

Thanks for your response.

Best regards.

David

[raga.fusionet · Accepted solution]

David,

What you are looking for is basically what is called preempt on a regular Active-Standby / Master-Backup, Routing scenario and unfortunately this is not supported for VPN connections. See below:

Note:

If you configured VPN with multiple  peer IP addresses for a crypto entry, the VPN gets established with the  backup peer IP once the primary peer goes down. However, once the  primary peer comes back, the VPN does not preempt to the primary IP  address. You must manually delete the existing SA in order to reinitiate  the VPN negotiation to switch it over to the primary IP address. As the  conclusion says, the VPN preempt is not supported in the site-to-site  tunnel.

Taken from here:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00805a87f7.shtml

I hope that clarifies your questions.

Have a good one.

PS: Please remember to mark this question as answered unless you have another question.

[david-lima]

Ohh, It is clear now. Thanks a lot Luis.

Best regards.

David

[raga.fusionet]

Sure anytime

[gabrielcossette]

Hi,

I found a "workaround" to make the box connect back automatically to the primary peer after a certain amount of time:

group-policy GROUP_POLICY_NAME attributes

vpn-session-timeout XX

Just replace with your group policy name and specify the amount of minutes in "vpn-session-timeout".

This setting will make the tunnel disconnect after this amount of time and when it will try to connect back (next time there is traffic), it will try the primary peer first.

Of course, this will cause a very short downtime while the tunnel is disconnecting/reconnecting. If you want no downtime at all that could happen during the day, scheduling a daily "clear crypto isakmp sa" sent from your network monitoring solution at night might be another solution.

[athukral]

Hello David,

Hope you must be doing fine!

Well  please mark the query answered and rate the same, if you  got the information you were  looking for.

Thanks

Ankur Thukral

Community  Manager- Security & VPN

athukral@cisco.com