Using packet tracer to troubleshoot ipsec tunnel - question...

[cchughes]

I have a site-to-site tunnel between two ASA's.  I was troubleshooting an issue where I cannot access a device on the remote site network and decided to use packet tracer via command line.  I ran the command and dont understand this output:

Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in  id=0x53c249e8, priority=0, domain=inspect-ip-options, deny=true
        hits=35826863, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

To me it says the result was to allow the packet yet deny=true.  My question is twofold.

1) Was the converstaion allowed?

2) If it was blocked, how does this output identify what blocked it?

I tried running "show access-list" and searching on the hex string after id= in the ouput, thinking that it pointed to an access list statement but that search failed.

Thanks in advance

[Jennifer Halim]

If the result from the packet tracer is "Allow" that means that the packet pass through just fine on that particular phase.

What is the overall result of the packet tracer?

Can you also share the output of:

show cry isa sa

show cry ipsec sa

and also what is actually failing? Thanks.

[cchughes]

The root problem is an ASA beyond ]the tunnel endpoint at the remote site.  I cant get ASDM working to it.  I was connected and suddenly ASDM stopped working.  I was using packet tracer to make sure I was getting across the tunnel to the remote site.  The remote ASA doesnt show anything in the logs that would indicate I am trying to connect to it.  My first step was to see if I was getting across the tunnel.  I have run sh cry isa and sh cry ips sa

and it shows that I have p1 established and a security association for that converstation that is encaps and decaps packets all day long.  Plus other traffic is using that association fine.  I dont understand why the packet tracer says deny=true.

[Jennifer Halim]

I just did a test and all my test is showing "deny=true" for the "inspect ip-options" phase, and the packet is allowed through.

it seems that it may not be conformed to the "ip-options" standard, however, the packet is still allowed through base on the "Result: ALLOW"

If you actually test traffic which is working fine through the tunnel, you will also find that for the "inspect ip-options" phase, the "Result:ALLOW" and it still shows "deny=true".

Here is more information on "inspect ip-options" if you are interested:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/i2.html#wp1744356

[cchughes]

Well that helped. I was able to stop focusing on the packet tracer long enough to spot the problem. Somehow the permit intra interface setting got turned off. Now the tunnel comes up, P1 and multiple P2 SA's come up but there is a P2 SA that isn’t showing up. I traced it and it looks like the remote end is encrypting it and putting it on the tunnel but all I can see at my end is:

Jan 05 2011 23:56:29: %ASA-7-609001: Built local-host outside:192.168.13.1

Jan 05 2011 23:56:29: %ASA-7-609002: Teardown local-host outside:192.168.13.1 duration 0:00:00

I cant for the life of me figure out why the SA doesn’t form. Is there a way to get more info on why this SA wont establish? I've checked acls and masks on both sides. All looks correct. I ran a debug of P2 but I don’t see any P2 associations trying to take place.

[Jennifer Halim]

If you can share the config from both ends and also advise which subnets are not working that would help.

[cchughes]

Sorry, I cant do that. I can answer questions and share portions of the config but we use public addressing which would give away who we are and that would be bad. Way to much involved in sanitizing the whole config. Starting a new thread that is specific to this issue.

[Bastien Migette]

Hello,

Using the show crypto ipsec sa, you can see #pkts decrypt / #pkts encrypt for each IPSEC SA, it can be a good indicator to see if traffic is reaching/leaving the device through the tunnel.

If no ipsec sa, check isakmp sa and/or crypto session/sockets.

Hope this help.

[cchughes]

Yes, as I stated in an earlier post, the caps and encaps are happening. The problem is that no SA is being negotiated for just one src/dst ACL used in the crypto map. That ACL covers multiple subnet pairs so far I see two subnet pairs that are not creating SA's. Strange. I'll start another thread for this as I've strayed from the original topic.