Re: Can't get PIX to attempt IPSec

tato386 · ‎12-11-2002

I am trying to get a PIX to start an IPSec session with an IOS router. It is a simple setup and I used the "Configuring IPSec - Router to PIX" document that I found on the TAC as a template. My problem seems that the PIX is not detecting interesting traffic. All IPSec debugs show zero packets and no errors. This makes sense cuz the PIX is not even trying to negotiate with the other peer. How can I debug if the packets match the access-list? Is there any equivalent to "debug ip packet 101" on the PIX?

Thanks,

Diego

gfullage · ‎12-11-2002

Te crypto debugs you want are "debug cry ipsec" and "debug cry isa", they should tell you if the PIX is trying anything.

If you're sure you're sending traffic that matches the access-list, and you're sure these packets are reaching the PIX, then you probably have a NAT problem, in that the PIX is NAT'ing the packets before they hit the crypto engine, they therefore don't match the crypto access-list anymore and aren't encrypted.

If you have say:

> access-list ipsectraffic permit 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

then you have to tell the PIX specifically not to NAT this traffic with:

> access-list nonat permit 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

> nat (inside) 0 access-list nonat

Leave everything else in place, just add this new ACL in the same as your crypto ACL (but with a different name), and the nat 0 command says "don't NAT this traffic".

tato386 · ‎12-12-2002

In order to see the output of "debug cry ipsec" and "debug cry isa" don't I need to do a "term mon" or something similar. I am using a telnet session to the PIX and do not see any output from these commands.

Here are the access-lists that I am using for NAT:

access-list nonat permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0

access-list nonat permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

We use both 192.168.0.0 and 10.0.0.0 private nets so the idea with the above is to not NAT any private traffic and to NAT all others

This is the IPSec access-list that I am trying to match:

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0

The PIX's inside interface sits on the 192.168.1.0 subnet. I am experimenting with IPSec between just these two subnets for now. Once I get it working I would add more IPSec access-lists for other subnets.

From what you are saying it seems like I would need an equal number of nonat lists to IPSec lists. I thought that by using the entire 192.168 and 10 blocks in the nonat I could take care of all subnets with just two lines.

Diego

mike-greene · ‎12-12-2002

Hi, that is correct, your going to have to do a "term mon" to see the debug output. If the PIX inside subnet is 192.168.1.0 and on the router side the subnet is 10.0.0.0/24, the your access list(s) need to read by source destination like your access-list 101.......

access-list nonat permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.255.0

Your access list 101 is correct and I'm assuming your using that in your crypto map config.......

crypto map company 10 match address 101

I have heard from Cisco engineers that you should not use the same access list for the nonat and the crypto map config. I have done this both ways and have not seen any problems with either one.

Hope this helps.....

gfullage · ‎12-12-2002

You can use the same access-list for your nonat and your crypto and it'll work fine. We usually suggest separating them because at some time later, if you go and add another crypto peer, you then HAVE to have them separated, since you need two separate crypto ACL's and you cna only have one NAT 0 ACL.