To Help Saving some typing, I was thinking of using Object-Groups for my ACLs.
I have about 8 Subnets that some are on one side of a VPN and some are on the other. In order to get the ACLs to allow traffic to pass from one another I have to create a matrix of one subnet to all of the others, so my ACLs get to be huge.
ip includes tcp, udp and icmp . So by using ip in your ACL you wont need any object-group protocol. And i am not sure that the crypto-map would support an acl using othre protocols than ip , so i would not bother with this one.
Remember that your crypto acl needs to be a mirror image of the peer acl. So i suggest that you create two object-group network. One for your inside subnets and one for your peer subnets.
For example ; object-group network NETWORK-VPN-INSIDE network-object 10.1.0.0 255.255.0.0 network-object 10.2.0.0 255.255.0.0 network-object 10.3.0.0 255.255.0.0 network-object 10.6.0.0 255.255.0.0
Both are running Cisco PIX Security Appliance Software Version 7.0(5)
Network is set up as follows:
10.1.x.x Internet Connection
10.3.x.x Serial T1 10.1.x.x
10.10.x.x Serial T1 10.1.x.x
10.11.x.x VPN Connection to 10.1.x.x
10.2.x.x Internet Connection
10.6.x.x Land to LAN 10.2.x.x
I've done something similar though I broke it down to Location object-group network NETWORK-OLIVET-ALL network-object 10.11.0.0 255.255.0.0 object-group network NETWORK-SF-VPN network-object 10.2.0.0 255.255.0.0 network-object 10.6.0.0 255.255.0.0 object-group network NETWORK-HBG-VPN network-object 10.1.0.0 255.255.0.0 network-object 10.3.0.0 255.255.0.0 network-object 10.10.0.0 255.255.0.0
NETWORK-OLIVET-ALL and NETWORK-HBG-VPN are on 'Inside' NETWORK-SF-VPN is at 'peer'
'Inside' PIX has the Following access-list inside_nat extended permit ip object-group NETWORK-OLIVET-ALL object-group NETWORK-SF-VPN access-list inside_nat extended permit ip object-group NETWORK-HBG-VPN object-group NETWORK-SF-VPN access-list outside-HBG_cryptomap_40 extended permit ip object-group NETWORK-HBG-VPN object-group NETWORK-SF-VPN access-list outside-HBG_cryptomap_40 extended permit ip object-group NETWORK-OLIVET-ALL object-group NETWORK-SF-VPN access-list outside-HBG_cryptomap_20 extended permit ip object-group NETWORK-HBG-VPN object-group NETWORK-SF-VPN access-list outside-HBG_cryptomap_20 extended permit ip object-group NETWORK-OLIVET-ALL object-group NETWORK-SF-VPN access-list outside-HBG_nat0_inbound extended permit ip object-group NETWORK-HBG-VPN object-group NETWORK-SF-VPN access-list outside-HBG_nat0_inbound extended permit ip object-group NETWORK-OLIVET-ALL object-group NETWORK-SF-VPN access-list outside-HBG_nat0_outbound extended permit ip object-group NETWORK-HBG-VPN object-group NETWORK-SF-VPN access-list outside-HBG_nat0_outbound extended permit ip object-group NETWORK-OLIVET-ALL object-group NETWORK-SF-VPN
'Peer' Pix has the Following: access-list inside_nat extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-HBG-VPN access-list inside_nat extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-OLIVET-ALL access-list outside-SF_nat0_outbound extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-HBG-VPN access-list outside-SF_nat0_outbound extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-OLIVET-ALL access-list outside-SF_cryptomap_20 extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-HBG-VPN access-list outside-SF_cryptomap_20 extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-OLIVET-ALL access-list outside-SF_nat0_inbound extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-HBG-VPN access-list outside-SF_nat0_inbound extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-OLIVET-ALL access-list charlie_tunnel extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-HBG-VPN access-list charlie_tunnel extended permit ip object-group NETWORK-SF-VPN object-group NETWORK-OLIVET-ALL
So here is my issue
10.2.x.x can see 10.6.x.x, 10.1.x.x , 10.11.x.x , 10.3.x.x 10.10.x.x Great it can see all
10.11.x.x can see 10.6.x.x, 10.1.x.x , 10.2.x.x , 10.3.x.x 10.10.x.x Great it can see all
10.3.x.x can see 10.6.x.x, 10.1.x.x , 10.2.x.x , 10.11.x.x 10.10.x.x Great it can see all
10.10.x.x can see 10.6.x.x, 10.1.x.x , 10.2.x.x , 10.3.x.x 10.11.x.x Great it can see all
10.6.x.x can see 10.2.x.x, 10.3.x.x, 10.10.x.x, 10.11.x.x It cannot see 10.1.x.x
10.1.x.x can see 10.2.x.x, 10.3.x.x, 10.10.x.x, 10.11.x.x It cannot see 10.6.x.x
10.2.x.x is connected to 10.6.x.x by a Netopia, I do not think that it is the issue as 10.6.x.x can see across the PIX to PIX VPN, then from the Remote Office PIX to PIX VPN to the 10.11.x.x network. So its hairpining at the 10.1.x.x to get to 10.11.
How can I trace the traffic to see where its being dropped?
I would start by doing a "sh crypto ipsec sa" on both PIX to validate that your crypto is properly configured.
Verify that you have a local ident and remote ident corresponding to the subnets 10.1 and 10.11 local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0) remote ident (addr/mask/prot/port): (10.11.0.0/255.255.0.0/0/0)
If you don't see it, you may have a crypto configuration problem on one side. If it's there, run a ping -t and check if packets are encapsulated and decapsulated
If you have some value for #pkts encaps , but #pkts decaps stays at 0 , it would normaly indicates that the packet reach the inside but you don't get the replies , meaning that you may have routing problems at the other side.
you can also put a capture on both PIX , and run your ping -t from both sides , to see what side is faulty
access-list capli permit ip 10.1.0.0 255.255.0.0 10.11.0.0 255.255.0.0 access-list capli permit ip 10.11.0.0 255.255.0.0 10.1.0.0 255.255.0.0
Thank you for your reply!!! I do appreciate it. I've been fighting with this on and off for months! I'll give your suggestions a try and report back...
Your results seems to indicate a valid crypto configuration and no routing issues. What is your access-group applied on the inside of Peer ? Maybe the packet gets dropped there.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.