When setting up or using site-to-site VPNs, you need to have an access list to specify which networks can talk to which remote networks. For this purpose, we typically use object and object-groups to make the access list more readable. What I have found is that when an object-group is used, it seems to frequently not use all the destination addresses even if they are in the object-group. The fix for this, we need to specify each network (both source and destination) individually. Yes, this will cause the access list to be much longer, but it will work for encrypting traffic.
Here’s an example of a recent VPN that was failing with this exact same issue:
Here are the group definitions:
Object-group COMPANY-LA
Network-object 10.50.0.0 255.255.224.0
Network-object 192.168.17.0 255.255.255.0
Object-group COMPANY-REMOTE
Network-object 10.50.32.0 255.255.240.0
Network-object 192.168.19.0 255.255.255.0
Here is the access-list for the crypto map to define interesting traffic:
access-list COMPANY-2-REMOTE extended permit ip object-group COMPANY-LA object-group COMPANY-REMOTE
The issue that we saw was traffic from 192.168.17.0/24 could not get to 192.168.19.0/24. We could see tunnel up and traffic from 10.50.0.0/19 to 10.50.32.0/20 would pass just fine. The fix for this was to specifically add the networks.
The final access-list looked like this:
access-list COMPANY-2-REMOTE extended permit ip 192.168.17.0 255.255.255.0 192.168.19.0 255.255.255.0
access-list COMPANY-2-REMOTE extended permit ip 192.168.17.0 255.255.255.0 10.50.32.0 255.255.240.0
access-list COMPANY-2-REMOTE extended permit ip 10.50.0.0 255.255.224.0 192.168.19.0 255.255.255.0
access-list COMPANY-2-REMOTE extended permit ip 10.50.0.0 255.255.224.0 10.50.32.0 255.255.240.0
When I changed the access list to the latter configuration all traffic would flow. Although this is not the way object-groups are supposed function, just be aware of this issue in your site-to-site VPNs.
Jason Howe, PEI
