• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4410
  • Last Modified:

Problem with IKE Phase 1 only working when initiated by one end.

Problem with IKE Phase 1 only working when initiated by one end.

We have a Cisco ASA at company Headquarters (HQ) with several IPSEC VPN connections to remote branch offices.

One branch office (BO) in particular has a problem with the VPN connection going down periodically and failing to reestablish.  Other branch offices are unaffected.


HQ ASA is a 5510 running 8.2(2)
Branch Office (BO) ASA is a 5505 runing 8.2(2)


Symptoms:

When the problem happens, "show crypto isakmp" on the BO ASA shows the following:


BO# sh crypto isakmp sa

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: [IP Address of HQ]
    Type    : user            Role    : initiator
    Rekey   : no              State   : MM_WAIT_MSG2

Global IKE Statistics
Active Tunnels: 0
Previous Tunnels: 275
In Octets: 2923644
In Packets: 33119
In Drop Packets: 1107
In Notifys: 29197
In P2 Exchanges: 682
In P2 Exchange Invalids: 0
In P2 Exchange Rejects: 0
In P2 Sa Delete Requests: 261
Out Octets: 3177924
Out Packets: 35483
Out Drop Packets: 0
Out Notifys: 59582
Out P2 Exchanges: 114
Out P2 Exchange Invalids: 0
Out P2 Exchange Rejects: 0
Out P2 Sa Delete Requests: 533
Initiator Tunnels: 595
Initiator Fails: 449
Responder Fails: 213
System Capacity Fails: 0
Auth Fails: 0
Decrypt Fails: 0
Hash Valid Fails: 0
No Sa Fails: 0

Global IPSec over TCP Statistics
--------------------------------
Embryonic connections: 0
Active connections: 0
Previous connections: 0
Inbound packets: 0
Inbound dropped packets: 0
Outbound packets: 0
Outbound dropped packets: 0
RST packets: 0
Recevied ACK heart-beat packets: 0
Bad headers: 0
Bad trailers: 0
Timer failures: 0
Checksum errors: 0
Internal errors: 0



In this state, Phase 1 never completes as long as the BO ASA is the initiator.

To bring the VPN back up, it is necessary to force the HQ ASA to initiate the IKE session.  I do this by doing a "clear crypto isakmp sa" on the BO ASA, while pinging a host on the BO LAN from the HQ LAN.


Once the BO ASA is the responder, IKE and IPSEC come back up:

WardsIsland# sh crypto isakmp

   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: [IP address of BO]
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE


Relevant Configuration:

HQ ASA:

access-list tunnel_cryptomap_BO extended permit ip 172.16.0.0 255.255.0.0 172.16.19.0 255.255.255.0
crypto ipsec transform-set prset esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000

crypto map tunnel_map 90 match address tunnel_cryptomap_BO
crypto map tunnel_map 90 set peer [IP address of BO]
crypto map tunnel_map 90 set transform-set prset
crypto map tunnel_map 90 set security-association lifetime seconds 3600
crypto map tunnel_map 90 set security-association lifetime kilobytes 4608000

crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 1
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400
no crypto isakmp nat-traversal


BO ASA:

access-list tunnel_cryptomap_HQ extended permit ip 172.16.19.0 255.255.255.0 172.16.0.0 255.255.0.0

crypto ipsec transform-set prset esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map tunnel_map 10 match address tunnel_cryptomap_HQ
crypto map tunnel_map 10 set peer [IP address of HQ]
crypto map tunnel_map 10 set transform-set prset
crypto map tunnel_map 10 set security-association lifetime seconds 3600
crypto map tunnel_map interface outside
crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 1
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400
no crypto isakmp nat-traversal

tunnel-group [IP address of HQ] type ipsec-l2l
tunnel-group [IP address of HQ] ipsec-attributes
 pre-shared-key *****
0
partners1998
Asked:
partners1998
  • 2
1 Solution
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
I don't know ASA well, but something obvious is that the HQ IKE info shows "user" as type, and a state of waiting - as if this was initiated using aggressive mode instead of main mode. However,
    tunnel-group [IP address of HQ] type ipsec-l2l
in the BO's ASA says different. But that setting is missing on the HQ site, so I would expect a mismatch, but the other way round (HQ being initiater failing).
0
 
ArneLoviusCommented:
you appear to be missing from the BO ASA

crypto map tunnel_map 10 set security-association lifetime kilobytes 4608000

Open in new window


on both ASAs you have

set transform-set prset

Open in new window


but you have not shown this on either config
0
 
partners1998Author Commented:
Thanks for the input - we tried a number of related changes, but were only able to resolve the problem by

Adding this on one side:
crypto map tunnel_map 90 set connection-type originate-only
And this on the other:
crypto map tunnel_map 10 set connection-type answer-only
0
 
partners1998Author Commented:
None of the solution offered resolved the issue, but adding these commands did.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now