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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
