cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
511
Views
5
Helpful
3
Replies

IPSEC SA ACL debug message

neil.robinson
Level 1
Level 1

Hi,

I'm currently setting up a site to site VPN tunnel between a PIX 515e and a customer Cisco 3000 series VPN concentrator.

I have configured all the ISAKMP policies and IPSEC rules. These should allow IP between two specific devices on mirrored ACL's.

However when IP ping from my source PC through the PIX to the customer end, the following IPSEC debug message appears on the PIX.

IPSEC(sa_initiate): ACL = deny; no sa created

IPSEC(sa_initiate): ACL = deny; no sa created

I have checked my acl's and cannot see any reason why this should stop the IPSEC tunnel from initiating.

Does anyone know what this message relates too? As I'm unable to find anything specific on cisco.com

I know the problem is somewhere on the PIX, as the VPN Concentrator does not see anything occuring in the live log.

I would very much appreciate anyone's help.

Many Thanks

Neil

1 Accepted Solution

Accepted Solutions

pcomeaux
Cisco Employee
Cisco Employee

Hey Neil -

I searched all the opened/closed TAC cases and received some info that may help you.

Here's the most likely results that have solved other customer problems:

1) Disable PFS on the PIX configuration for that tunnel as the Concentrator does not uses PFS

2) Rebooting the Pix or using the clear crypto sa's command

3) Changing the ACLs from any any to more specific source/destination pairs.

4) Ensuring sysopt ipsec permit was enabled

5) Double checking the No Nat ACLs and the crypto map ACLs

I think #1 may be the most likely cause. You've probably already have done #2. #3 & #5 you should check on as this might be possible, but it might already be correct. #4 is probably not the cause since you are not seeing any activity on the concentrator.

Let us know if none of these help and I will look into other cases a more deeply.

Hope this helps,

peter

View solution in original post

3 Replies 3

pcomeaux
Cisco Employee
Cisco Employee

Hey Neil -

I searched all the opened/closed TAC cases and received some info that may help you.

Here's the most likely results that have solved other customer problems:

1) Disable PFS on the PIX configuration for that tunnel as the Concentrator does not uses PFS

2) Rebooting the Pix or using the clear crypto sa's command

3) Changing the ACLs from any any to more specific source/destination pairs.

4) Ensuring sysopt ipsec permit was enabled

5) Double checking the No Nat ACLs and the crypto map ACLs

I think #1 may be the most likely cause. You've probably already have done #2. #3 & #5 you should check on as this might be possible, but it might already be correct. #4 is probably not the cause since you are not seeing any activity on the concentrator.

Let us know if none of these help and I will look into other cases a more deeply.

Hope this helps,

peter

Cheers Peter!

I have amended the ACL to specifically allow icmp between the source and dest addresses. These has done the trick.

Top man!

Many Thanks

Neil

Hi Peter,

I get the same log message. However, my tunnels run either PIX-to-PIX or Router-to-PIX.

Of the suggestions:

1) Disable PFS on the PIX configuration for that tunnel as the Concentrator does not uses PFS

PFS NOT BEING USED.

2) Rebooting the Pix or using the clear crypto sa's command

CLEARED THE SAs. NOT REBOOTED YET. WILL TRY THAT TONIGHT.

3) Changing the ACLs from any any to more specific source/destination pairs.

ALCS ARE PERFECT MIRRORS FOR ALL IP.

4) Ensuring sysopt ipsec permit was enabled

ENABLED.

5) Double checking the No Nat ACLs and the crypto map ACLs

NO NAT ACLS PERMIT TRAFFIC (SO BYPASSING NAT).

Besides these, any other suggestions?

By the way, the tunnels have been working for a few months now.....issue just arose yesterday after a major IP change at one location (but that has been verified) and an IOS upgrade on a router that is one of the peers.