VPN works in one direction but not another

Unanswered Question
Mar 2nd, 2010

I have a problem which is driving me crazey!

I have two sites which I am trying to connect togther. Newmarket and Thetford

When I try to bring up a tunnel between Newamrket (orginate only) and Thetford (answer only) via the backup interface the VPN tunnel is formed and traffic flows from both sites.

But..

If I change directions so that Thetford is answer only and Newmarket is orignate only via the backup interface it fails.

The debug from the Newmarket site is as below:-

I am foxed as to why I can create a VPN from one direction but not another!

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 184

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing SA payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, Oakley proposal is acceptable

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received NAT-Traversal ver 02 VID

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received NAT-Traversal ver 03 VID

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received Fragmentation VID

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715064: IP = 88.96.85.174, IKE Peer included IKE fragmentation capability flags:  Main Mode:        True  Aggressive Mode:  True

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing IKE SA payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715028: IP = 88.96.85.174, IKE SA Proposal # 1, Transform # 1 acceptable  Matches global IKE entry # 2

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing ISAKMP SA payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing NAT-Traversal VID ver 02 payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing Fragmentation VID + extended capabilities payload

2010-03-02 14:58:38    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 128

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing ke payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing ISA_KE payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing nonce payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received Cisco Unity client VID

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received xauth V6 VID

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715038: IP = 88.96.85.174, Processing VPN3000/ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715049: IP = 88.96.85.174, Received Altiga/Cisco VPN3000/Cisco ASA GW VID

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing NAT-Discovery payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, computing NAT Discovery hash

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: IP = 88.96.85.174, processing NAT-Discovery payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, computing NAT Discovery hash

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing ke payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing nonce payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing Cisco Unity VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing xauth V6 VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715048: IP = 88.96.85.174, Send IOS VID

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715038: IP = 88.96.85.174, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715048: IP = 88.96.85.174, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing NAT-Discovery payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, computing NAT Discovery hash

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: IP = 88.96.85.174, constructing NAT-Discovery payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, computing NAT Discovery hash

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, Connection landed on tunnel_group 88.96.85.174

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, Generating keys for Responder...

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 296

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 92

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing ID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-714011: Group = 88.96.85.174, IP = 88.96.85.174, ID_IPV4_ADDR ID received<010>192.168.28.2

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715076: Group = 88.96.85.174, IP = 88.96.85.174, Computing hash for ISAKMP

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715034: IP = 88.96.85.174, Processing IOS keep alive payload: proposal=32767/32767 sec.

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing VID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715049: Group = 88.96.85.174, IP = 88.96.85.174, Received DPD VID

2010-03-02 14:58:39    Local4.Info    200.0.0.100    %ASA-6-713172: Group = 88.96.85.174, IP = 88.96.85.174, Automatic NAT Detection Status:     Remote end   IS   behind a NAT device     This   end   IS   behind a NAT device

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: IP = 88.96.85.174, Connection landed on tunnel_group 88.96.85.174

2010-03-02 14:58:39    Local4.Warning    200.0.0.100    %ASA-4-713903: Group = 88.96.85.174, IP = 88.96.85.174, Freeing previously allocated memory for authorization-dn-attributes

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing ID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715076: Group = 88.96.85.174, IP = 88.96.85.174, Computing hash for ISAKMP

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715034: IP = 88.96.85.174, Constructing IOS keep alive payload: proposal=32767/32767 sec.

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing dpd vid payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 92

2010-03-02 14:58:39    Local4.Info    200.0.0.100    %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 88.96.85.174

2010-03-02 14:58:39    Local4.Error    200.0.0.100    %ASA-3-713119: Group = 88.96.85.174, IP = 88.96.85.174, PHASE 1 COMPLETED

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713121: IP = 88.96.85.174, Keep-alive type for this connection: DPD

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715080: Group = 88.96.85.174, IP = 88.96.85.174, Starting P1 rekey timer: 82080 seconds.

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-714003: IP = 88.96.85.174, IKE Responder starting QM: msg id = fa31536a

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE RECEIVED Message (msgid=fa31536a) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 184

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing SA payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing nonce payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing ID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-714011: Group = 88.96.85.174, IP = 88.96.85.174, ID_IPV4_ADDR ID received<010>192.168.28.2

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713025: Group = 88.96.85.174, IP = 88.96.85.174, Received remote Proxy Host data in ID Payload:  Address 192.168.28.2, Protocol 0, Port 0

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing ID payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-714011: Group = 88.96.85.174, IP = 88.96.85.174, ID_IPV4_ADDR ID received<010>88.96.81.102

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713024: Group = 88.96.85.174, IP = 88.96.85.174, Received local Proxy Host data in ID Payload:  Address 88.96.81.102, Protocol 0, Port 0

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715047: Group = 88.96.85.174, IP = 88.96.85.174, processing notify payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, QM IsRekeyed old sa not found by addr

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713221: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, checking map = backup_map, seq = 20...

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713222: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, map = backup_map, seq = 20, ACL does not match proxy IDs src:192.168.28.2 dst:88.96.81.102

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713221: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, checking map = backup_map, seq = 20...

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713222: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, map = backup_map, seq = 20, ACL does not match proxy IDs src:192.168.28.2 dst:88.96.81.102

2010-03-02 14:58:39    Local4.Error    200.0.0.100    %ASA-3-713061: Group = 88.96.85.174, IP = 88.96.85.174, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.28.2/255.255.255.255/0/0 local proxy 88.96.81.102/255.255.255.255/0/0 on interface backup

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, sending notify message

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing blank hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing qm hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE SENDING Message (msgid=90ce7f3c) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 236

2010-03-02 14:58:39    Local4.Error    200.0.0.100    %ASA-3-713902: Group = 88.96.85.174, IP = 88.96.85.174, QM FSM error (P2 struct &0x41274e0, mess id 0xfa31536a)!

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715065: Group = 88.96.85.174, IP = 88.96.85.174, IKE QM Responder FSM error history (struct &0x41274e0)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_NEGO_SA-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, sending delete/delete with reason message

2010-03-02 14:58:39    Local4.Error    200.0.0.100    %ASA-3-713902: Group = 88.96.85.174, IP = 88.96.85.174, Removing peer from correlator table failed, no match!

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, IKE SA MM:e96527ff rcv'd Terminate: state MM_ACTIVE  flags 0x0001c042, refcnt 1, tuncnt 0

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, IKE SA MM:e96527ff terminating:  flags 0x0101c002, refcnt 0, tuncnt 0

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713906: Group = 88.96.85.174, IP = 88.96.85.174, sending delete/delete with reason message

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing blank hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing IKE delete payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-715046: Group = 88.96.85.174, IP = 88.96.85.174, constructing qm hash payload

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713236: IP = 88.96.85.174, IKE_DECODE SENDING Message (msgid=295bcce3) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 76

2010-03-02 14:58:39    Local4.Warning    200.0.0.100    %ASA-4-113019: Group = 88.96.85.174, Username = 88.96.85.174, IP = 88.96.85.174, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found

2010-03-02 14:58:39    Local4.Notice    200.0.0.100    %ASA-5-713904: IP = 88.96.85.174, Received encrypted packet with no matching SA, dropping

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
slmansfield Tue, 03/02/2010 - 08:59

Looks like your access-lists associated with the IPSEC SAs do not match.  They should be mirror images of each other.

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713222: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, map = backup_map, seq = 20, ACL does not match proxy IDs src:192.168.28.2 dst:88.96.81.102

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713221: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, checking map = backup_map, seq = 20...

2010-03-02 14:58:39    Local4.Debug    200.0.0.100    %ASA-7-713222: Group = 88.96.85.174, IP = 88.96.85.174, Static Crypto Map check, map = backup_map, seq = 20, ACL does not match proxy IDs src:192.168.28.2 dst:88.96.81.102

2010-03-02 14:58:39    Local4.Error    200.0.0.100    %ASA-3-713061: Group = 88.96.85.174, IP = 88.96.85.174, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy

mawallace Tue, 03/02/2010 - 09:02

That is what I thought - but when I looked at my configs I could not see that they did not! And why will it work in one direction and not the other?

Could you have a look at my configs that I zipped and see if you can see where they do not match?

slmansfield Tue, 03/02/2010 - 09:12

Is this the crypto map you are using on Newmarket?  I don't see an access-list applied.

crypto map backup_map 20 set connection-type answer-only
crypto map backup_map 20 set peer 88.96.85.174
crypto map backup_map 20 set transform-set ESP-3DES-MD5
crypto map backup_map 20 set reverse-route
crypto map backup_map interface backup

I'm also wondering whether the crypto access-list on Thetford is pointing to Newmarket?

access-list backup_20_cryptomap extended permit ip Thetford_LAN 255.255.255.0 Bury_LAN 255.255.255.0

crypto map backup_map 20 match address backup_20_cryptomap
crypto map backup_map 20 set connection-type answer-only
crypto map backup_map 20 set peer 88.96.71.198
crypto map backup_map 20 set transform-set ESP-3DES-MD5
crypto map backup_map 20 set reverse-route
crypto map backup_map interface backup
crypto map back_map 20 set connection-type answer-only

mawallace Wed, 03/03/2010 - 01:28

I have tried reconfiguring the access lists overnight but still no success.

Same problem as before:-

I can bring tunnel up, with no problems, by setting Newmarket as orginate only and Thetford as answer only. This would seem to me to indicate therefore that the ACL's match.

But.. as soon as I set the config as below, it does not work. Same errors as before!

At Newmarket (which is 88.96.81.102) by the way I have:-

name 200.0.0.0 Newmarket_LAN description Newmarket Local Area Network
name 210.0.0.0 Thetford_LAN description Thetford Local Area Network

access-list backup_cryptomap_1 extended permit ip Newmarket_LAN 255.255.255.0 Thetford_LAN 255.255.255.0

crypto map backup_map 1 match address backup_cryptomap_1
crypto map backup_map 1 set connection-type answer-only
crypto map backup_map 1 set peer 88.96.85.174
crypto map backup_map 1 set transform-set ESP-3DES-MD5
crypto map backup_map 1 set reverse-route
crypto map backup_map interface backup

At Thetford (which is 88.96.85.174) I have:-

-

name 200.0.0.0 Newmarket_LAN description Newmarket Local Area Network
name 210.0.0.0 Thetford_LAN description Thetford Local Area Network

access-list backup_cryptomap_1 extended permit ip Thetford_LAN 255.255.255.0 Newmarket_LAN 255.255.255.0

crypto map backup_map 1 match address backup_cryptomap_1
crypto map backup_map 1 set connection-type originate-only
crypto map backup_map 1 set peer 88.96.81.102
crypto map backup_map 1 set transform-set ESP-3DES-MD5
crypto map backup_map 1 set reverse-route

slmansfield Wed, 03/03/2010 - 05:47

Is the crypto map applied to the backup interface on the Thetford device?

Could you post your current debugs?

thx

slmansfield Wed, 03/03/2010 - 06:54

I reviewed your prior debug and found this.

88.96.85.174, Static Crypto Map check, map = backup_map, seq = 20, ACL does not match proxy IDs src:192.168.28.2 dst:88.96.81.102

Your peer endpoints don't match what is in your crypto configuration.  I think the following command will resolve the issue.  Set the identity to the peer address so it is not using the address of the backup interface.

crypto isakmp identity

To set the Phase 2 ID to be sent to the peer, use the crypto isakmp identity command in global configuration mode. To return to the default setting, use the no form of this command.

crypto isakmp identity {address | hostname | key-id key-id-string | auto}

no crypto isakmp identity {address | hostname | key-id key-id-string | auto}

slmansfield Wed, 03/03/2010 - 08:30

It shows again that your proxies do not match the IPSEC peer addresses.  I think adding the command I gave you on both devices will address this issue.  The local proxy address should match the peer address in the remote peer's crypto map.

2010-03-03 15:59:30 Local4.Debug 210.0.0.100 %ASA-7-713906: Group = 88.96.81.102, IP = 88.96.81.102, Transmitting Proxy Id:<010>  Local host:  192.168.28.2  Protocol 0  Port 0<010>  Remote host: 88.96.81.102  Protocol 0  Port 0

(0) total length : 64
2010-03-03 15:59:30 Local4.Debug 210.0.0.100 %ASA-7-715009: Group = 88.96.81.102, IP = 88.96.81.102, IKE Deleting SA: Remote Proxy 88.96.81.102, Local Proxy 192.168.28.2
2010-03-03 15:59:30 Local4.Error 210.0.0.100 %ASA-3-713902: Group = 88.96.81.102, IP = 88.96.81.102, Removing peer from correlator table failed, no match!

mawallace Wed, 03/03/2010 - 09:20

I think (!) between us I have worked out the answer.

As you say, the identiy being broadcast is the backup interface. I think it fails because the idenity is not in the ACL.

Looking at the configs, it would appear I have a dynamic rule on each interface, except the backup at Newmarket.

Also, looking at the logs etc, putting it into debug, it seems that none of the VPN tunnel's match up when they connect but they fall back onto the dynamic "catch all" rule!

So, I will try adding the dynamic rule when I can bring the VPN's down at the remote site in the next few days.

Looking at the crypto isakmp identity command, it lloks as if the two interfaces would have the same idenity - so how do I tell in the cofing what the expected ideitiy should be - as otheriwse it breaks the VPN tunnel on the inside interface unless I use host name rather than ip address

When it goes to connect it see the wrong ip addresses on the outside interface, as using the crpto isakmp command it now thinks it is coiming from the outside!

e.g If I set the idenity to host name, I will need in my crptomaps to put the expected hostname into the config's somewhere. I can;t figure that one out!!

slmansfield Wed, 03/03/2010 - 11:44

I think the issue is that your IPSEC peers are not addresses on your ASAs, they are defined by static routes.

The use of dynamic crypto maps sounds like a good plan to eliminate the need to match IPSEC peers by known addresses.

Actions

This Discussion