2 simultaneous site to site VPN tunnels with 3 PIX

I have been having a tough time setting up 3 PIX devices so that all 3 have 2 tunnels to the other 2. I can only get one to keep both tunnels open, making a chain instead of a fully connected triangle. When I managed to bring up the 2nd tunnel on another, it broke the 1st tunnel, leaving me in the same situation. The config for all 3 is nearly identical, so variations in behavior are especially perplexing. 2 are using 6.3(5) and 1 on 6.3(3). Any suggestions would be appreciated.

access-list 100 permit ip 192.168.1.0 255.255.255.0 192.168.11.0

255.255.255.0 access-list 100 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0 access-list 100 permit ip 192.168.1.0 255.255.255.0 172.17.2.0 255.255.255.0 access-list 110 permit ip 192.168.1.0 255.255.255.0 172.17.2.0 255.255.255.0 access-list 120 permit ip 192.168.1.0 255.255.255.0 192.168.11.0 255.255.255.0

nat (inside) 0 access-list 100

sysopt connection permit-ipsec crypto ipsec transform-set myset esp-3des esp-md5-hmac crypto dynamic-map dynmap 30 set transform-set myset crypto map newmap 1 ipsec-isakmp crypto map newmap 1 match address 120 crypto map newmap 1 set peer [office1] crypto map newmap 1 set transform-set myset crypto map newmap 10 ipsec-isakmp crypto map newmap 10 match address 110 crypto map newmap 10 set peer [office2] crypto map newmap 10 set transform-set myset crypto map newmap 20 ipsec-isakmp dynamic dynmap crypto map newmap interface outside isakmp enable outside isakmp key ******** address [office1] netmask 255.255.255.255 no-xauth no-config-mode isakmp key ******** address [office2] netmask 255.255.255.255 no-xauth no-config-mode isakmp identity address isakmp nat-traversal 3600 isakmp policy 1 authentication pre-share isakmp policy 1 encryption 3des isakmp policy 1 hash md5 isakmp policy 1 group 2 isakmp policy 1 lifetime 86400

Reply to
maction555
Loading thread data ...

There's nothing obviously wrong with the excerpt you show.

Possibilities to examine:

- double check that you do not accidently reuse an ACL name. Using the same ACL for different purposes causes weird behaviour.

- I would suggest adding additional higher-priority (lower- numbered) policies. You are currently using 3DES MD5 Group2. I suggest highest priority as AES-128 SHA Group5, then 3DES SHA Group2, then

3DES MD5 Group2. (AES-128 is faster than 3DES, including on the models that have VAC or VAC+. And AES is more secure. And SHA is more secure than MD5.)
Reply to
Walter Roberson

ACL 100, 110, and 120 have the same destination networks listed. This should confuse the PIX and fail. Each ACL should be unique.

Reply to
Joe Beasley

No, you are incorrect. Have another look at the usage:

access-list 100 permit ip 192.168.1.0 255.255.255.0 192.168.11.0 255.255.255.0 access-list 100 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0 access-list 100 permit ip 192.168.1.0 255.255.255.0 172.17.2.0 255.255.255.0 access-list 110 permit ip 192.168.1.0 255.255.255.0 172.17.2.0 255.255.255.0 access-list 120 permit ip 192.168.1.0 255.255.255.0 192.168.11.0 255.255.255.0

nat (inside) 0 access-list 100

and 110 and 120 are used in seperate crypto map match address policies.

There is no overlap between the destinations of 110 and 120 (the crypto map policies) and 110 and 120 are not visibly used for anything else, so there is no conflict between 110 and 120.

100 shares destinations with 110 and 120, but 100 is used in a different way, for the nat 0 access-list, which defines which traffic is to be exempt from network address translation.

This setup is the correct way to define LAN to LAN traffic between sites in which the various LANs see the internal IPs of the other LANs.

Reply to
Walter Roberson

Also ACL 100 is being used to define split tunneling. The original config works BTW, it was just that the traffic I was generating from the server was not enough to initiate the tunnel for some reason. Once the users came in the AM and started pounding away it came right up.

Walter Robers> > >ACL 100, 110, and 120 have the same destination networks listed.

Reply to
maction555

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.