[c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel

[Ryan West]

Scott,

A pointer for your ACLs, wrap up your secured networks into two object-groups.  For example:

Object-group network internal 
 Network-object 10.1.0.0 255.255.0.0
 Network-object 10.1.0.0 255.255.0.0
.....

Object-group network ny_nets
 Network-object 10.18.14.0 255.255.255.0

Then craft your interesting traffic ACL on the ASA to look something like this:

Access-list vpn_ny permit ip object-group internal object-group ny_nets

Access-list nonat permit ip object-group internal object-group ny_nets

Any future changes are done at the object-groups and will be immediately reflected in your interesting traffic ACL and nonat ACL.

As Michael has said, the error can be a number of things, I would start with the crypto key though.  A lot of the ISAKMP settings (at least in the ASA) are part of the default config and cover just about every common Phase1 setting.  From the ASA, issue a 'show cry isa sa detail' and check out the entry that corresponds with your PIX endpoint.  Post the results of that once you've got a stream of interesting traffic going from the ASA to the PIX.  If possible post the debug results from the PIX to the ASA with the settings that I mentioned earlier, if there is a key mismatch, you'll see that error on the ASA side.

In case you're curious, this is the 7.2.4 bug I was referring to as well, it exists through 7.2.4(18):

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq91271

-ryan

-----Original Message-----



Scott,

Can you provide debugs from the ASA, code versions on both devices and
your
associated no-nat ACLs?

Assuming you have nothing else logging to monitor, you can enable
'logging
class vpn monitor debug' and throw up a term mon to gather inbound
messages
to the ASA from the PIX side.  You can gather the information on the PIX

with a debug cry isa 2 and then initiate interesting traffic from the
ASA
using the following, the more valuable information will be on the
receiving
end.  It really doesn't matter which side you enable as the receiver,
but I
try to stay away from pre 7.x code on the PIXes.

packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed

Phase: 10 or 11 should be subtype encrypt.  If it fails the first time,
run
it again, the negotiation process causes the first packet to fail as the

tunnel is being brought.  This type of traffic will also give you your
debug
information and help you figure out where the failure is.

-ryan