PIX 6.3 Site-toSite Connection - Just adding to crypto map problem

Greetings, I recently tried to get a customer site up via a PIX to PIX l2l VPN. I'll start with the issue that did not work after we gave up on the initial issue...Site A already has a site to site with Site B. Not all the networks needed are going across it. VPN config stuff....

---Site A--- access-list outside_crypto_map_13 permit ip 172.20.8.0 255.255.252.0

172.20.0.0 255.255.252.0 access-list outside_crypto_map_13 permit ip 172.20.12.0 255.255.255.0 172.20.0.0 255.255.252.0 access-list outside_crypto_map_13 permit ip 172.21.8.0 255.255.252.0 172.20.0.0 255.255.252.0 access-list nonat permit ip 172.20.8.0 255.255.252.0 172.20.0.0 255.255.252.0 access-list nonat permit ip 172.20.12.0 255.255.255.0 172.20.0.0 255.255.252.0 access-list nonat permit ip 172.21.8.0 255.255.252.0 172.20.0.0 255.255.252.0 nat (inside) 0 access-list nonat sysopt connection permit-ipsec crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto map outside_map 13 ipsec-isakmp crypto map outside_map 13 match address outside_crypto_map_13 crypto map outside_map 13 set pfs group2 crypto map outside_map 13 set peer 1.1.1.1 crypto map outside_map 13 set transform-set ESP-3DES-SHA crypto map outside_map interface outside isakmp enable outside isakmp key ******** address 1.1.1.1 netmask 255.255.255.255 isakmp identity address isakmp policy 10 authentication pre-share isakmp policy 10 encryption 3des isakmp policy 10 hash sha isakmp policy 10 group 2 isakmp policy 10 lifetime 86400

---Site B--- access-list nonat permit ip 172.20.0.0 255.255.252.0 172.20.16.0

255.255.252.0 access-list nonat permit ip 172.21.0.0 255.255.252.0 172.21.16.0 255.255.252.0 access-list nonat permit ip 172.20.0.0 255.255.252.0 172.20.216.0 255.255.255.0 access-list nonat permit ip 172.20.0.0 255.255.252.0 172.20.8.0 255.255.252.0 access-list nonat permit ip 172.20.0.0 255.255.252.0 172.21.16.0 255.255.252.0 access-list nonat permit ip 172.20.0.0 255.255.252.0 172.20.12.0 255.255.255.0 access-list nonat permit ip 172.20.0.0 255.255.252.0 172.21.8.0 255.255.252.0 access-list outside_crypto_map_11 permit ip 172.20.0.0 255.255.252.0 172.20.8.0 255.255.252.0 access-list outside_crypto_map_11 permit ip 172.20.0.0 255.255.252.0 172.20.12.0 255.255.255.0 access-list outside_crypto_map_11 permit ip 172.20.0.0 255.255.252.0 172.21.8.0 255.255.252.0 sysopt connection permit-ipsec crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto map outside_map 11 ipsec-isakmp crypto map outside_map 11 match address outside_crypto_map_11 crypto map outside_map 11 set pfs group2 crypto map outside_map 11 set peer 2.2.2.2 crypto map outside_map 11 set transform-set ESP-3DES-SHA crypto map outside_map interface outside isakmp enable outside isakmp key ******** address 2.2.2.2 netmask 255.255.255.255 isakmp identity address isakmp policy 10 authentication pre-share isakmp policy 10 encryption 3des isakmp policy 10 hash sha isakmp policy 10 group 2 isakmp policy 10 lifetime 86400

In the above configuration....site a can talk to the 172.20.x.x networks with no problems. Site B can talk to Site A via it's 172.20 network no problem. After I could not get Site A to talk to Site B and C properly, I reverted to just working on A to B/B to A comms. We want site A networks to talk to the site Bs 172.21.x.x networks. So, I thought since there was an existing tunnel that worked, I'd just modify the crypto maps and nat 0 statements. Something like...

Site A access-list outside_crypto_map_13 permit ip 172.21.8.0 255.255.252.0

172.21.0.0 255.255.252.0 access-list outside_crypto_map_13 permit ip 172.21.8.0 255.255.252.0 172.21.20.0 255.255.252.0

access-list nonat permit ip 172.20.8.0 255.255.252.0 172.16.0.0

255.255.240.0 access-list nonat permit ip 172.20.12.0 255.255.255.0 172.16.0.0 255.255.240.0 access-list nonat permit ip 172.21.8.0 255.255.252.0 172.16.0.0 255.255.240.0 !There is more stuff, but in this case 172.21.8.x should be able to talk to any 172.16.x.x network at site B

Site B access-list outside_crypto_map_11 permit ip 172.21.0.0 255.255.252.0

172.20.8.0 255.255.252.0 access-list outside_crypto_map_11 permit ip 172.21.0.0 255.255.252.0 172.20.12.0 255.255.255.0 access-list outside_crypto_map_11 permit ip 172.21.0.0 255.255.252.0 172.21.8.0 255.255.252.0 access-list nonat permit ip 172.21.0.0 255.255.252.0 172.20.8.0 255.255.252.0 access-list nonat permit ip 172.21.0.0 255.255.252.0 172.21.8.0 255.255.252.0

If I'm not mistaken, 172.21.8.x should freely be able to talk to 172.21.0.x and vice-versa. There should be no reason why not. Any suggestions? The other part of this setup is a different store.

Reply to
CeykoVer
Loading thread data ...

As long as you crypto map and no-nat statements are identical this should be fine.

Out of interest, where is site C.

If site A wants to talk to site C via site B, I take it you have a route on site B to C.

When you look at the crypto ACL (site A Pix), are you receiving hits for the site C traffic. What does show crypto ipsec sa tell you. What do the encaps / decaps say.

Regards

Darren

Reply to
Darren Green

Hey Darren, The scope of this post was for A to B and B to A conversation. However, your questions apply to both the posts I made last night. For the single A-B comms, the tunnel is fine from a show crypto ipsec sa and show crypto isakmp sa. We saw encaps/decaps but were not able to ping, telnet...etc to devices on the network(s) we specified. THat's what has me stumped the most. If I could've gotten the A-B and B-A comms working, I'd be in okay shape.

However, the actual plan was for site A to talk with B and C via A-B tunnel and A-C tunnel. A-B tunnel was there, but A-C was new and I was never able to get that tunnel established. I got a seperate post about that portion, but I'm not against posting here if you're interest.

I appreciate the post up.

Reply to
CeykoVer

OK.

I looked throught the above config again and focussing on Site A & Site B the ACL's look fine. I am sure it was just how you pasted the e- mail though but your Site B configuration does not have: 'nat (inside)

0 access-list nonat' in the config.

NB When looking at this I have removed the entries for everything else down to:

Site A:

access-list outside_crypto_map_13 permit ip 172.20.8.0 255.255.252.0

172.20.0.0 255.255.252.0 access-list nonat permit ip 172.20.8.0 255.255.252.0 172.20.0.0 255.255.252.0

Site B:

access-list nonat permit ip 172.20.0.0 255.255.252.0 172.20.8.0

255.255.252.0 access-list outside_crypto_map_11 permit ip 172.20.0.0 255.255.252.0 172.20.8.0 255.255.252.0

You say you are getting encrypts & decrypts on site A, what are you getting on site B. What sits in between these 2 x devices - routers etc.

On site B how is the routing done back to site A. Is the firewall the default gateway or another device. If another device is their a route on this device pointing back to the subnet of site A via the PIX.

I believe that PDM has a logging tool on it's GUI. Have you looked to see what this may give you. Alternatively you could use capture lists on the PIX to see what is happenning on the outside and inside of the Firewall (see

formatting link
for capture lists).

Regards

Darren

Reply to
Darren Green

Hey Darren, Again, thanks a million for posting up. Normal routers are all that's in between the two PIX firewalls (besides all the usual Internt routers.:)) and each pix is connected to a 3750 stack, that has the PIX as the default gateway. There is just plain jane static routing otherwise. Our testing was from connected networks on each end of the PIX, so routing did not have much a play in the matter at that time.

It seems you're where I was...time to get some logging going. This will certainly be my next step tonight if I have a problem, ran out of time last night. Appreciate your input. Was trying to verify there was nothing glaringly wrong.

Take care

Reply to
CeykoVer

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.