cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
883
Views
0
Helpful
13
Replies

VPN ACL Question

edw
Level 1
Level 1

Hi,

I have setup a PIX515E with ACLs for VPN RA. I am now trying to setup a VPN to L2L. I have gone through the documentation etc and double and triple checked everything. However when I ping from my internal machine to the VPN network I get this in my syslog

Deny icmp src inside:11.54.54.54 dst outside:172.138.123.1 (type 8, code 0) by access-group "Outbound"

My VPN ACL is configured on my crypto and I have another for nonat.

The Outbound ACL group is for standard traffic passing from my inside interface into the PIX. Do I also have to add enteries into here for the VPN network...

This would be 3 ACL's then for VPN L2L which is OTT surely ?? Or is there another reason ??

Thanks

Ed

13 Replies 13

andrew.prince
Level 10
Level 10

Ed,

At the moment that is exactly how is sounds on the ACL comment. Can you post your config?

HTH/.

Hi,

Unfortantly I'd rather not post config to much editing right now. I suppose the question is - how many acl would one except to do L2L the book shows 2 - however it doesnt say if one of these is a access-group or not....

Thanks

Ed

Ed,

In thoery 2 - one for "interesting traffic" what the device should encrypt/decrypt and "no nat" what NOT to NAT for the VPN.

However by the looks of your first posting, you a limiting traffic into the PIX inside interface - outbound...this would indicate you will have some issues getting traffic from your local LAN into the VPN.

I suggest you debug, log, perform captures...and depending if you have the ASDM in your device and configured to use. There is a tool, that is coming along - use the packet tracer (i am against any kind of GUI based troublshooting - but this may help you)

HTH.

Thanks - that confirmed my suspiscioun - intreastingly enough I have now added the ACL into the outbound group too, and althought the vpn is connecting yet - it now starting isakmp phase 1. Weird, either cisco documentation isn't fully explained or something is wrong. I understnad I have a ACL on my interface but I wold have thought the PIX to be a bit intelligent and check crypto's for ACL too before dropping it.

So basically if someone has a PIX with say 3 or more interfaces which each have a ACL for normal workflow (say internet access and DMZ) and then you setup a L2L VPN. You have to add entries to 3 different ACL's ...????

Thanks

Ed

Ed,

The PIX/ASA is after all a firewall. Saying that the device MUST recevie traffic into an interface for the device to procees it against an ACL's/NAT rules that you have configured for VPN services. If your ACL's on the interface does not include an entry for the remote VPN LAN - how can the device know that it needs to bring up the VPN, if the interface has already dropped the traffic???

Remeber in ALL types of devices with access-lists.....if it matches - it performs the action.

You would only need to add to acl entries IF you are filtering traffic on the inbound interface.

HTH.

Hi,

I filter all traffic going into the PIX on all interfaces. I just assumed as the examples etc I have seen don't mention any interface ACL it wasn't needed.

I have to admin I don't like the fact that there are 3 ACLs all pretty identical to get the job done. Okay I understand the interface ACL - but surely I should be able to merge the nonat and crypto one.... very annoying and a lot of work for people. Hope version 9 or even 8 abates this..

Thanks

Ed

Ed,

Don't forget about the interface security-level command. This could help with your config, if implemented correctly.

You could converge the no-nat rule. But i don't think you would want to do that on the Crypto, but that is just my opionion.

HTH.

Hi,

Do you think I should created a sub interface for this work ?? Is that what you mean... The nonat acl is combinded with my RA VPN nonat as I can have only one 0 nat per interface..

Thanks

Ed

Ed,

To be honest - it's whatever works for you, you just need to look at your design - and future requirements; and build your rule base around that.

Hi,

I am bascially trying to connect a PIX and Linksys 4400N router.

When I check the linksys log it says

May 12 17:58:45 - [VPN Log]: "Support" #4: sending encrypted notification INVALID_ID_INFORMATION to X.X.X.43:500

May 12 17:58:53 - [VPN Log]: "Support" #4: received Vendor ID payload [Dead Peer Detection]

May 12 17:58:53 - [VPN Log]: "Support" #4: Main mode peer ID is ID_IPV4_ADDR: 'X.X.X.14'

May 12 17:58:53 - [VPN Log]: "Support" #4: no suitable connection for peer 'X.X.X.14'

Any ideas - its obviously seeing that my PIX has a natted interface - ..

Thanks

Ed

andrew.prince
Level 10
Level 10

Ed,

I thought this has already been covered, in previous responses; unless I am missing someting?

Hi,

Sory this is probably moving to another part of the problem ;) After adding to the above metiond interface ACL it now starts to handshack with the Linksys product. However fails - it seems the Linksys box doesnt like the fact the PIX ip is natted. IE its expected the external WAN IP but when it peer id check it gets its natted IP and then fails.... right pain!

Thanks

Ed

Ed,

If the remote Linksys does not like the PIX being behind another device, then I suggest you enable Nat Traversal on the PIX. This should might overcome the issue with the Linksys.

As presiously said - this would have gone alot somether with sanitised configs. Having nothing to work with makes it difficult, so can you post the entire output from:-

debug crypto isakmp

debug crypto ipsec

debug crypto engine

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: