Confused with VPN I have setup

jamesgonzo · ‎07-22-2008

Hi,

I have setup a VPN between a Cisco 877 DSL router to a Cisco Concentrator. It all works, and I (My PC 192.168.20.10) can access 172.30.2.10 (A PC on the 877 LAN) - great.

1.) But why is it I can remove the ACL called "inbound" from the "dialer 1" interface inbound and nothing is affected. The traffic all still works. Surely removing this should stop my accessing the remote PC on the 877.

It is as if the ACL is being bypassed.

2.) Has it got anything to do with the SA's on each side of the tunnel? "access-list 101 permit ip 172.30.2.0 0.0.0.255 any"

3.) I'm not sure if the SA or as some call them "protected networks" which would be 172.30.2.0/24 and "any" are allowing the traffic through?

michael.leblanc · ‎07-22-2008

The absence of an interface ACL results in all traffic being permitted on an interface.

The crypto ACL is relevant in the following scenarios:

(1) If traffic that should be encapsulated (i.e.: matches crypto ACL), arrives un-encapsulated, it would be dropped.

(2) If traffic that should not be encapsulated (i.e.: doesn't match crypto ACL), arrives encapsulated, it would be dropped.

On a separate note, your ACL contains the following ACEs:

permit udp any any eq isakmp

permit esp any any

... which will result in the following ACEs never being matched:

permit esp host 1.1.1.73 any

permit udp host 1.1.1.73 any eq isakmp

Also, it is not recommended practice to use the keyword "any" in a crypto ACL. It is best to be specific about the traffic that is to be protected.

Unfortunately, the Network IDs being used aren't contiguous, and don't provide an opportunity for "reasonable" summarization.

If you were to do this:

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.30.0 0.0.0.255

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.40.0 0.0.0.255

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.50.0 0.0.0.255

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.60.0 0.0.0.255

... you would end up with a pair of IPSec SAs for each flow (ACE) resulting in increased crypto overhead.

If you were using contiguous Network IDs, they could be summarized with fewer ACEs.

e.g.: Network IDs 192.168.16.0 0.0.0.255 through 192.168.23.0 0.0.0.255, could be summarized with:

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.16.0 0.0.7.255

... resulting in a single pair of IPSec SAs.

The 20, 30, 40 , etc. may look well organized, but it bites you in many different circumstances.

jamesgonzo · ‎07-23-2008

Great reply.

I have removed the:

permit udp any any eq isakmp

permit esp any any

and kept:

permit esp host 1.1.1.73 any

permit udp host 1.1.1.73 any eq isakmp

This is much better.

I have thought about adding just the subnets and remove the "any" on the Crypto ACL, but I also tunnel the sites Internet requests over the VPN as we have to monitor it at the HQ, am I right in saying the "any" covers the Internet page requests too, if I were to add just the protected subnets would the Internet stop working?

michael.leblanc · ‎07-23-2008

Given your need to encapsulate all traffic to/from the branch office, I would leave it as it is.

In situations where you do not need to encapsulate traffic destined to "any" destination, I would avoid use of the "any" keyword, and use summarization to minimize the number of ACEs in the crypto ACL.

jamesgonzo · ‎07-23-2008

Your suggestion to summarization makes sense, Ithought about using:

access-list 101 permit ip 172.30.2.0 0.0.0.255 192.168.0.0 0.0.255.255

But then the internet wouldn't work, thanks for your help.