cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1654
Views
0
Helpful
3
Replies

Limitation with Number of Entries in a Split Tunnel ACL

nma_xdcinema
Level 1
Level 1

Hi Cisco community !

I am facing an issue with a Cisco Hub and spoke solution.

We have 2 Hubs (Cisco 7200 - 2 for redudancy). Every customer have a Spoke (Cisco 881). The Spokes are 24/24 connected to the 2 hubs (2 dmvpn tunnels) to give us the access to our equipments of monitoring and for support.

Every Spoke have a NAT table with a specific NAT range for every Spoke. Like this we can reach every devices with a unique IP inside the VPN.

For example:

     - Spoke_001 have a NAT IP range of 10.80.0.0 255.255.254.0

     - Spoke_002 have a NAT IP range of 10.80.2.0 255.255.254.0

     ...

To connect to the hubs with our laptops, we are using the Cisco VPN client. We have different profiles created in the hubs:

- Admin profile with an ACL that allow the connectivity to every Spoke

- Integrator profiles: that allow the connectivity of one integrator to some defined Spokes.

So the integrator profile looks like this in the hub

crypto isakmp client configuration group [NAME]

key [PASSWORD]

domain [DOMAIN]

pool [NAME]

acl [NAME_VPN_Split]

!

crypto isakmp profile [NAME]

           description VPN clients profile group [NAME]

           match identity group [NAME]

   client authentication list VPN_Client_AUTHEN

   isakmp authorization list VPN_Client_AUTHOR

   client configuration address respond

ip local pool [NAME] ....

And the access list link to this group:

ip access-list extended [NAME_VPN_Split]

permit ip 10.82.20.0 0.0.1.255 any

permit ip 10.82.24.0 0.0.1.255 any

permit ip 10.81.238.0 0.0.1.255 any

permit ip 10.82.4.0 0.0.1.255 any

permit ip 10.82.44.0 0.0.1.255 any

permit ip 10.81.242.0 0.0.1.255 any

...

In this access list, we can modify subnets to reduce the number of entries but some groups needs to have access to Spoke with NAT IP range that we can't summarize in 1 ligne (see example under)

The issue we have is: When we have more than 50 entries in the ACL, the 51st entry is not working:

- VPN client doesn't receive the route to this network, the route is then not added on the PC connected

- Even if the route is added manually on the PC, the 51st network of the ACL is not reachable.

Do you know why is there a limitation of 50 entries in a "Split tunnel ACL" ?

Do you know if there is a solution to avoid this issue ?

The problem is that if we can't summarize an ACL in less than 50 lines, we will have to create a second profile and to know wich one to use for wich network... Not really a good solution.

Thanks in advance !!

Version:

ROM: System Bootstrap, Version 12.3(4r)T3, RELEASE SOFTWARE (fc1)

BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.3(15), RELEASE SOFTWARE (fc3)

System image file is "disk2:c7200-advsecurityk9-mz.151-4.M2.bin"

1 Accepted Solution

Accepted Solutions

Jennifer Halim
Cisco Employee
Cisco Employee

Yes, there is a hard limit of 50 split tunnel ACL entries when you configure it using the older way of configuring VPN (ie: crypto map).

If you are using the dynamic VTI to configure it, then you don't have any limitation for the split tunnel ACL.

Here is a sample config for dynamic VTI configuration:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/15-mt/sec-ipsec-virt-tunnl.html#GUID-E9EB4518-6269-42E8-908C-57BA5D6334A5

Hope that answers your question.

View solution in original post

3 Replies 3

Jennifer Halim
Cisco Employee
Cisco Employee

Yes, there is a hard limit of 50 split tunnel ACL entries when you configure it using the older way of configuring VPN (ie: crypto map).

If you are using the dynamic VTI to configure it, then you don't have any limitation for the split tunnel ACL.

Here is a sample config for dynamic VTI configuration:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/15-mt/sec-ipsec-virt-tunnl.html#GUID-E9EB4518-6269-42E8-908C-57BA5D6334A5

Hope that answers your question.

Tested and working !!! I didn't know about this limitation before.

I tried it in our lab and I will implement this ASAP on our hubs.

Great, thanks a lot !

Excellent, and thanks for the update.