The Local Zoo - Cisco Troubleshooting and Configuration

Potential PIX OS 6.3.2 bug

We've been having a bit of a nightmare at work recently... One of the major points has been Pix to Pix VPN connections, between a LAN (lan1) at one site, and a LAN (lan2) and DMZ at another. The VPN needs to go from the lan1, to the DMZ, because a machine in the DMZ needs to speak to a couple of machines on lan1, using their internal private IP addresses (I know, I know, big security hole, but it's a front end/back end exchange server configuration and there's not a great deal I can do about that...). The VPN was up, and traffic was flowing from lan1 to lan2, and from lan1 towards the DMZ, but traffic wasn't finding its way back from the DMZ to lan1, we were just logging "no route" from the pix. Now this is strange in itself, because the Pix was being told to encrypt traffic to lan1, from the DMZ, and the VPN is effectively a connected interface. Eventually, we got a Cisco consultant in (many thanks Mike if you're reading this), and after a few days of scratching his head, he found us the answer. Basically, the pix at the site of the DMZ was not performing as he would expect pix OS to perform, and he could demonstrate it working fine on later versions of the pix OS. The issue was static translations. We originally had a relevant line for a private IP range :
static (intf1,intf2) 192.168.0.0 192.168.0.0 netmask 255.255.0.0 0 0
The fix was to break this line down into the individual subnets we actually wanted to connect to :
static (intf1,intf2) 192.168.55.0 192.168.55.0 netmask 255.255.255.0 0 0
static (intf1,intf2) 192.168.56.0 192.168.56.0 netmask 255.255.255.0 0 0
Crazy but true!!