Using Object-Groups in ACLs?

Yes you can use groups with no problems;

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

object-group network NETWORK-VPN-PEER network-object 10.10.0.0 255.255.0.0 network-object 10.11.0.0 255.255.0.0 network-object 10.12.0.0 255.255.0.0 network-object 10.13.0.0 255.255.0.0

with whatever subnet belonging to each group

wich would give on one side; access-list outside_nat0_outbound extended permit ip object-group NETWORK-VPN-INSIDE object-group NETWORK-VPN-PEER

and on the other side; access-list outside_nat0_outbound extended permit ip object-group NETWORK-VPN-PEER object-group NETWORK-VPN-INSIDE

wich would give on one side; access-list outside_nat0_inbound extended permit ip object-group NETWORK-VPN-INSIDE object-group NETWORK-VPN-PEER

and on the other side; access-list outside_nat0_inbound extended permit ip object-group NETWORK-VPN-PEER object-group NETWORK-VPN-INSIDE

wich would give on one side; access-list outside_cryptomap_40 extended permit ip object-group NETWORK-VPN-INSIDE object-group NETWORK-VPN-PEER

and on the other side; access-list outside_cryptomap_40 extended permit ip object-group NETWORK-VPN-PEER object-group NETWORK-VPN-INSIDE

Thank you for your reply.

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?

Thanks, Scott

see below

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

#pkts encaps: 2981815, #pkts encrypt: 2981815, #pkts digest: 2981815 #pkts decaps: 4025268, #pkts decrypt: 4025268, #pkts verify: 4025268

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

capture capin access-list capli interface inside

sh capture capin (no capture capin when done )

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...

Scott see below

So I have a Ping -t going in both Directions, Reset the VPN Connection.

So it looks like from the info below that Inside is not receiving

packets being sent by peer.

It looks like peer is sending the packets, though not encapting them.

I feel much closer, though not sure what to do next..

Scott 10.6.0.1: icmp: echo request

2: 12:55:52.074489 10.1.0.133 > 10.6.0.1: icmp: echo request 3: 12:55:57.066921 10.1.0.133 > 10.6.0.1: icmp: echo request 4: 12:56:02.105402 10.1.0.133 > 10.6.0.1: icmp: echo request 5: 12:56:07.063824 10.1.0.133 > 10.6.0.1: icmp: echo request 6: 12:56:12.062603 10.1.0.133 > 10.6.0.1: icmp: echo request 7: 12:56:17.062695 10.1.0.133 > 10.6.0.1: icmp: echo request 8: 12:56:22.062313 10.1.0.133 > 10.6.0.1: icmp: echo request 9: 12:56:27.062084 10.1.0.133 > 10.6.0.1: icmp: echo request 10: 12:56:32.068294 10.1.0.133 > 10.6.0.1: icmp: echo request 11: 12:56:37.061764 10.1.0.133 > 10.6.0.1: icmp: echo request

Peer

peer# sh capture capin

35 packets captured 1: 12:55:51.353802 10.6.0.11.1213 > 10.1.0.8.53: udp 40 2: 12:55:51.975657 10.1.0.133 > 10.6.0.1: icmp: echo request 3: 12:55:51.976130 10.6.0.1 > 10.1.0.133: icmp: echo reply 4: 12:55:52.352307 10.6.0.11.1213 > 10.1.0.8.53: udp 40 5: 12:55:53.933133 10.6.0.6 > 10.1.0.1: icmp: echo request 6: 12:55:54.352337 10.6.0.11.1213 > 10.1.0.8.53: udp 40 7: 12:55:56.353939 10.6.0.11.137 > 10.1.0.7.137: udp 50 8: 12:55:56.968074 10.1.0.133 > 10.6.0.1: icmp: echo request 9: 12:55:56.968532 10.6.0.1 > 10.1.0.133: icmp: echo reply 10: 12:55:57.852266 10.6.0.11.137 > 10.1.0.7.137: udp 50 11: 12:55:59.352276 10.6.0.11.137 > 10.1.0.7.137: udp 50 12: 12:55:59.433128 10.6.0.6 > 10.1.0.1: icmp: echo request 13: 12:55:59.948010 10.6.0.11.1213 > 10.1.0.11.53: udp 40 14: 12:55:59.949291 10.6.0.11.137 > 10.1.0.7.137: udp 50 15: 12:56:00.852250 10.6.0.11.137 > 10.1.0.11.137: udp 50 16: 12:56:00.946255 10.6.0.11.1213 > 10.1.0.11.53: udp 40

7.0(5)

NETWORK-OLIVET-ALL

NETWORK-HBG-VPN

object-group

object-group

NETWORK-SF-VPN

NETWORK-SF-VPN

NETWORK-SF-VPN

NETWORK-SF-VPN

10.10.x.x

10.10.x.x

10.10.x.x

10.11.x.x

it is

the

hairpining

validate

the

one

encapsulated and

2981815

4025268

at 0

have

both

for my

are

one

others, so

you wont

othre

peer

and one

10.2.0.0

10.3.0.0

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.

Can you post a sanitized config of both PIX

So it looks like my last post never made it. )-:

So I forgot my Golden rule of IT. If its not working, Reboot first, then try it again...

I didn't think that applied to PIXs. I did logoff the LAN to LAN VPN connection between the two PIXs via the ADSM.

Thank you again for your help!

Scott