PIX multiple site to site problem

what does show crypto isakmp sa on each pix show you?

it sounds like you have lost your site to site vpn tunnels...

I am assuming that this is configured as a Hub and spoke config, as mentioned here: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080093bd3.shtml

when you say all clients are down, is this at both remote sites? where are the resources that they are trying to access?

what do the logs say on both sides of the vpn tunnel say when activities fail?

Yes, they are dependant. And yes you will need to change the PIX 515's configuration to match the new IP address. Beyond knowing the password, you will also have to come from the right IP address for the tunnel to come up. Just another level of security.

I would add that the ip addresses for the pixes in the vpn config identifies the end points for the VPN tunnel, it isn't about security, it is the end point for the tunnel. The two phase encrypted key exchange is the security bit.

If you  moved the pix to a different ip address without changing the termination point for the VPN there is no hope for the VPN to work...

Hope this helps,

-t

I will check the logs and change the IP tomorrow and post my results. So if I am understanding correctly, if one peer cannot negotiate an IKE SA then that could cause the other peer to not work correctly. Hence my issue and the dependancy. What do you mean that I need to come from the right IP to bring the tunnel back up, from where should I do this?

So if I am understanding correctly, if one peer cannot negotiate an IKE SA then that could cause the other peer to not work correctly. Hence my issue and the dependancy. What do you mean that I need to come from the right IP to bring the tunnel back up, from where should I do this?

in the example that i posted there are three pixes, pix central, pix2, and pix3.

pix central has an external ip of 172.18.124.153 255.255.255.0
pix2 has an external ip of 172.18.124.154 255.255.255.0
pix3 has an external ip of 172.18.124.157 255.255.255.0

on pix central the vpn tunnel for pix2 is defined as having a preshared key and a terminal ip address, that of the local interface of pix2:


!--- This is traffic to PIX 2.

crypto map newmap 20 ipsec-isakmp
crypto map newmap 20 match address 120
crypto map newmap 20 set peer 172.18.124.154
crypto map newmap 20 set transform-set myset
isakmp key ******** address 172.18.124.154 netmask 255.255.255.255 no-xauth no-config-mode

on pix2 the same pre-shared key must exist as well as the other remote address, that of pix central:


!--- This is traffic to PIX Central.

crypto map newmap 10 ipsec-isakmp
crypto map newmap 10 match address 110
crypto map newmap 10 set peer 172.18.124.153
crypto map newmap 10 set transform-set myset
crypto map newmap interface outside
isakmp key ******** address 172.18.124.153 netmask 255.255.255.255 no-xauth no-config-mode



it is not clear to me why both remote clients would go down if only one has changed, but then I might not understand your config.

I am assuming that you would want your 501s to be pix2 and pix3 and your other pix to act as pix central.

hope this helps

-t

If PIX-A changed its outside interface's IP address but the configuration of the PIX-515 was not changed to reflect this, it would never allow the VPN to come up even if PIX-A was to initiate the connection and had all the right ISAKMP password and everything. That's what I meant about another level of security. You can have the right password but you have to tell the PIX-515 what IP address to expect that connection from.
As to both sites being down, I didn't read clearly and missed that part. I also don't know why that would have brought down both tunnels. Make sure to configure all 3 sites properly and then make sure to clear out the tunnels manually. 'clear cry sa'
Then watch the debugs and see what's going on.

I did notice one thing in one remote office. A Windows 2000  Pro box logged on with no issues and works great. Any XP Pro box with the same exact config has trouble. Ever see that before?

Can you verify that you have the configurations all matching up now? That the main hub PIX 515 has the new IP address of RemoteA configured? Don't try to figure out why something works or not if you haven't gotten that far yet. All sorts of things could happen when your set up is misconfigured. No use in troubleshooting that.

I have verified all the configs on each PIX and they are correct. The one office that continues to have an issue does have a hub connected to the LAn and then into the PIX. I wonder if that is causiing issues.  I did do a show isakmp sa on the cental PIX and it showed:

state QM_IDLE  pending 0 created 4
state QM_IDLE  pending 0 created 2

QM_IDLE means you're Phase 1 tunnel is up. Do a 'show cry ips sa' to see if your Phase 2 tunnels are up. You should see an inbound and outbound ESP SAS connection for each remote site. The encap/decap ratio should be roughly the same on those tunnels too.

Okay.  pkts encap 120098  encrypt 120098  digest 120098
          pkts decap 104818  decrypt 104878  verify 104875

No errors or failures.

Is that from the main PIX or the remote? If it is from the main PIX then you should have two Phase 2 tunnels.

Or rather, you would have one per source/destination pair.

That was from the central PIX.

So you're saying that you only saw one Phase 2 tunnel even though there were two Phase 1 tunnels?

valicon-

I think photograffiti has you in good hands...

FYI this is from http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml

Background Theory

IPSec negotiation can be broken down into five steps, including two Internet Key Exchange (IKE) phases.

   1.      An IPSec tunnel is initiated by interesting traffic. Traffic is considered interesting when it travels between the IPSec peers.
   2.      In IKE Phase 1, the IPSec peers negotiate the established IKE Security Association (SA) policy. Once the peers are authenticated, a secure tunnel is created using Internet Security Association and Key Management Protocol (ISAKMP).
   3.      In IKE Phase 2, the IPSec peers use the authenticated and secure tunnel to negotiate IPSec SA transforms. The negotiation of the shared policy determines how the IPSec tunnel is established.
   4.      The IPSec tunnel is created and data is transferred between the IPSec peers based on the IPSec parameters configured in the IPSec transform sets.
   5.      The IPSec tunnel terminates when the IPSec SAs are deleted or when their lifetime expires.

Note: IPSec negotiation between the two PIXs fails if the SAs on both of the IKE phases do not match on the peers.

No I saw two, I only listed the one that was affected.

Well, it looks like both tunnels are up for both Phases. What are the symptoms at this point? What can ping where and what can't? When you ping between sites, do you see the encaps/decaps increasing an equal amount - about 4 each?

The same. Windows clients cannot bind to the domain. When the client attempts to logon, it takes 20-30 minutes and then the desktop appears, but the client is not logged on to the domain. If you try to access any network resources, it will prompt for user ID and password.  I can ping anything on the domain. I will need to check the encaps/decaps as I ping. Typically this will be a DNS issue, but we triple checked that and we are only having issues from clients coming over the VPN.

So connectivity is not the issue? Then I was totally off. If you can ping everywhere then we're talking about different things. If you're having slow logon issues, then I think it's a MTU issue. I've ran into this before.
To test, use the Set MTU utility that comes with Cisco's VPN client to change the MTU of a single PC's NIC. Reboot and then try connect across the VPN once it gets back up.

What is interesting is that Windows 2000 Pro clients are not affected as bad, the logon is slow, but they can at least access resources. What should I change the MTU to?  

Okay will do. I will try it tomorrow and let you know.  Thanks for your help :)

Worked like a charm!

Awesome. Glad it did.