PIX-to-PIX IPSec VPN

[o.goencz]

I have two sites connected through IPSec VPN tunnel. Each site's PIX has number of interfaces and the same VPN tunnel is used to allow network traffic between the different interfaces. This set up has been working just fine for an extended period of time, however; two weeks ego the VPN tunnel stopped functioning between DMZ on PIX(local) and TBD on PIX(remote) interfaces. Other interfaces between the local and remote PIX are still functioning, the VPN tunnel is up and the traffic is flowing without any issues.

The traffic was captured between the DMZ and TBD interfaces:

The packet capture on the remote PIX shows that the requests do leave the remote PIX, but the responses don't return.

The packet capture on the local PIX shows the request arriving from the remote PIX and response is sent out from the device.

Additionally, the "sh crypto ipsec sa" on the local PIXshows:

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 201, #pkts decrypt: 201, #pkts verify 201

The local PIX has been rebooted recently.

The same command on the remote PIX shows:

#pkts encaps: 40393499, #pkts encrypt: 40393499, #pkts digest 40393499

#pkts decaps: 30452041, #pkts decrypt: 30452041, #pkts verify 30452041

The #pkts decaps line has not changed for the last two weeks.

The Cisco tech suggested a number of changes on the local PIX, including rebooting, but neither of them resolved the issue. The changes applied to the local PIX were "cosmetic" changes to the NAT and access lists.

I'm hoping that some of you might have a better suggestion to resolve this issue.

TIA..

Otto

[mhussein]

Did you clear the "ipsec sa" entry on the remote PIX?

It would be helpful if you could post your configs.

Regards

Mustafa

[o.goencz]

Thanks for your help...

The "clear crypto ipsec sa" command was issued at both the local and remote PIX's. Additionally the local PIX reboot also cleared the "xlate", "arp", and other parameters. The command line version of these parameters were used to clear the same on the remote PIX.

The company policy does not allow posting firewall configuration in public forums, sorry.

Otto

[kingnascar]

From the limited amount of info given here it does look like a crypto acl might indeed be the issue. It looks like you have a one-way session which is indicative of a acl problem. (or possibly a route has changed).

[o.goencz]

Thanks for the tip, the crypto was one of the aspect of the configuration what we've looked at also.

The crypto acl is/was ok and finally Cisco resolved the issue. It turned out to be the static NAT statement which has caused the problem with the VPN tunnel.

In the process of fixing the issue I've re-learned the order of NAT the PIX processes the configuration:

NAT 0

Static

NAT

PAT

The Cisco tech, who actually fixed the configuration issue after two weeks, insisted that the above is the proper order. I hesitantly removed the offending static NAT statement, since I believed that the static has priority over NAT 0 and it's been in place forever, but it did restore the VPN tunnel. I also contacted my former trainer Dave, who verified the above order the PIX processes the translations.

Yes, I do trust Cisco tech support... :)

Otto