cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
761
Views
0
Helpful
5
Replies

IPSEC VPN ACLs

Mikey John
Level 1
Level 1

Hi,

 

I needed some help with the VPN ACLs I have setup in my Internet gateway router. I have provided access between the following networks on the IPSEC VPN, and it seems to be working fine.

 

Source (Point A)

10.204.47.0/26
10.204.47.64/27
10.204.47.96/27
10.204.47.128/27
10.204.47.160/27
10.204.48.0/27
10.204.48.32/27
10.204.48.64/27
10.204.105.0/24

 

Destination (Point B)

10.204.31.0/24
10.204.32.0/21
10.204.40.0/23


Now, as part of a new requirement, the customer needs access to the whole 10.204.0.0/18 and 10.204.64.0/18 networks from point A. I tried adding the following ACLs at both the ends end to see if the traffic passes through, but the traffic was still getting dropped at the internet facing interface.

 

A end
======
permit ip 10.204.0.0 0.0.63.255 10.204.0.0 0.0.63.255
permit ip 10.204.64.0 0.0.63.255 10.204.64.0 0.0.63.255

 

B End
=====
permit ip 10.204.0.0 0.0.63.255 10.204.0.0 0.0.63.255
permit ip 10.204.64.0 0.0.63.255 10.204.64.0 0.0.63.255

 

1) Why it does not seem to hit the VPN ACL and pass through if I have allowed the whole /18 blocks?
2) Also, will it work if I add something like permit <source subnet> destination any?


I feel I am missing something basic here. Appreciate your help


Thanks
Mikey

5 Replies 5

Hello,

 

hard to say without seeing the full config of your router, can you post that ?

HI George,

 I'll send that across soon. But, for now, I just needed to know if the given ACL statements for the /18 blocks would work?

 

 

Thanks

Mikey

Julio E. Moisa
VIP Alumni
VIP Alumni

Hi

You could require create a NAT to avoid the traffic is NAT'd to Internet before to pass through the VPN tunnel. 

 

 




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Hi Julio,

 

 I don't need to configure a NAT as Iam routing all the private IP space over an IPSEC tunnel to the destination. This is not getting routed anywhere on the Internet.

 

These are the current ACLs in place in the router at A end. 

 

 permit ip 10.204.47.0 0.0.0.63 10.204.31.0 0.0.0.255
 permit ip 10.204.47.0 0.0.0.63 10.204.32.0 0.0.7.255
 permit ip 10.204.47.0 0.0.0.63 10.204.40.0 0.0.1.255
 permit ip 10.204.47.64 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.47.64 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.47.64 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.47.96 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.47.96 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.47.96 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.47.128 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.47.128 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.47.128 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.47.160 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.47.160 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.47.160 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.48.0 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.48.0 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.48.0 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.48.32 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.48.32 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.48.32 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.48.64 0.0.0.31 10.204.31.0 0.0.0.255
 permit ip 10.204.48.64 0.0.0.31 10.204.32.0 0.0.7.255
 permit ip 10.204.48.64 0.0.0.31 10.204.40.0 0.0.1.255
 permit ip 10.204.105.0 0.0.0.255 10.204.31.0 0.0.0.255
 permit ip 10.204.105.0 0.0.0.255 10.204.32.0 0.0.7.255
 permit ip 10.204.105.0 0.0.0.255 10.204.40.0 0.0.1.255

 

 

Can I add these two lines and make it work? Please note that the source and destination subnets are all part of a bigger /16 block, and it has been used in different geographical locations. I just need to know if this ACL statement would work or not?

 

 permit ip 10.204.0.0 0.0.63.255 10.204.0.0 0.0.63.255
 permit ip 10.204.64.0 0.0.63.255 10.204.64.0 0.0.63.255

Mikey John
Level 1
Level 1

Hi,

 I atleast got the reply for my 2nd question (see link below), and it makes sense.

 

When you create crypto access lists, using the any keyword could cause problems. Cisco discourages the use of the any keyword to specify source or destination addresses.

 

https://supportforums.cisco.com/t5/wan-routing-and-switching/question-about-acls-for-crypto-map/td-p/1784780

 

 Excerpts below

 

 

The permit any any statement is strongly  discouraged, as this will cause all outbound traffic to be protected  (and all protected traffic sent to the peer specified in the  corresponding crypto map entry) and will require protection for all  inbound traffic. Then, all inbound packets that lack IPSec protection  will be silently dropped.

 

You need to be sure you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

 

 

 

The 10.204.x.x/17 is the supernet we have for this customer, and there are multiple subnets from that big block which have been assigned in many places. So, would it make sense to do the following since both source and destination are part of this big block?

 

permit ip 10.204.0.0 0.0.63.255 10.204.0.0 0.0.63.255
permit ip 10.204.64.0 0.0.63.255 10.204.64.0 0.0.63.255

 

Thanks

Mikey