02-27-2005 06:59 AM - edited 02-21-2020 01:38 PM
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
02-27-2005 01:34 PM
Did you clear the "ipsec sa" entry on the remote PIX?
It would be helpful if you could post your configs.
Regards
Mustafa
02-28-2005 05:08 AM
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
03-04-2005 03:14 PM
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).
03-06-2005 04:28 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide