VPN ACL Explanation

[agrayson]

I have a fail over VPN Site to Site VPN solution that I inherited when hired a couple months ago. I understand the interesting traffic Permit ACL but there is also a extremly large deny ACL. I am trying to follow the packet so I can explain the entire process to management. I am going to replace this solution using the DMVPN solution hopefully. Our current solution is not scalable as we add more spokes ...the ACLs get to big. Here is a sample of our VPN solution. Again I am just trying to follow the packet and understand how the DENY ACL works...we have a VOIP solution in place as well so each spoke will need to talk to each spoke for voice,,,10 sites will not be failed over but 1 may and it needs to continue to communicate.

[andrew.prince]

The first thing I would do would be to get a grip on the ACL's and start summarizing them to get a better idea, this will also reduce the size of the acl.

[agrayson]

Thanks for the quick response. The solution does work and works well but is not scalable. Believe me we want to summarize but the issue is we have 20 remote sites/(subnets) and lets say site 1 fails over to VPN connection solution and sites 2-20 are still connected normally to WAN then from what I see is the deny ACL on the Headend keeps non nat traffic away...IE the sites still connected to normal WAN connection. I am in the process of getting this in a lab but I think VPN/GRE and IPSEC vai DMVPN is a much better solution. But I must be able to explain the OLD current solution and why I want to migrate to the DNVPN solution.

[andrew.prince]

I would proably use a dynamic routing protocol, in GRE tunnels over the VPN connections. This way you can control the traffic from remote site to remote site via the hub central site - using either an acl or distibute lists.