We have an IPSec VPN tunnel between two pix firewalls that provides access to a private, remote network. We've had problems in the past with the tunnels only coming up when traffic from ONE direction was seen, but not the other. i.e., if the tunnel was down, only traffic going OUT to the remote site would cause the tunnel to come up. ONce it did, traffic flowed fine in both directions. I figured that it was because the local pix was configured to allow certain subnets within our class B (in the ipsec rules) while the remote pix was configured to allow the entire class B. I reconfigured the remote pix to match which subnets the local pix had and it seemed to clear things up.
However, a few days ago, I've suddenly found that I have the opposite problem. If a tunnel goes down (expires due to inactivity or whatever) then only traffic coming from the REMOTE site will bring it back up. Not all tunnels are showing this behavior, but I suspect that that is only because a number of tunnels have regular traffic coming FROM the remote site (namely, domain controllers talking back and forth to each other.)
Here are what I believe to be the relevant portions of the config from each pix (with IP's and such sanitized for your protection.) Both units are PiX 515E's with software version 7.0(2).
Local Unit:
access-list outside_cryptomap_15 extended permit ip object-group AccessGroup 10.40.0.0 255.255.255.0 access-list outside_cryptomap_15 extended permit ip object-group AccessGroup 10.1.0.0 255.255.255.0 access-list outside_cryptomap_15 extended permit ip host BackupServer
10.20.0.0 255.255.255.0crypto ipsec transform-set kzoovpn2 esp-3des esp-sha-hmac crypto map kzoomap 15 match address outside_cryptomap_15 crypto map kzoomap 15 set pfs crypto map kzoomap 15 set peer crypto map kzoomap 15 set transform-set kzoovpn2 crypto map kzoomap 15 set security-association lifetime seconds 86400 crypto map kzoomap 15 set security-association lifetime kilobytes
30608000 crypto map kzoomap interface outsideRemote Unit: access-list outside_cryptomap_10 extended permit ip 10.40.0.0
255.255.255.0 object-group KNET_Tunnel access-list outside_cryptomap_10 extended permit ip 10.20.0.0 255.255.255.0 host BackupServer access-list outside_cryptomap_10 extended permit ip 10.1.0.0 255.255.255.0 object-group KNET_Tunnelcrypto ipsec transform-set kzoovpn esp-3des esp-sha-hmac crypto map outside_map 10 match address outside_cryptomap_10 crypto map outside_map 10 set pfs crypto map outside_map 10 set peer crypto map outside_map 10 set transform-set kzoovpn crypto map outside_map 10 set security-association lifetime seconds
86400 crypto map outside_map 10 set security-association lifetime kilobytes 30608000Note that KNET_Tunnl and AccessGroup contain the same members.
I'm uncertain if this is a configuration issue or not, though, as it's had this config for a while now (4 or 5 months) and we haven't had any problems. Then, all of a sudden we start getting reports of people coming in in the morning (on certain less used subnets) and they can't reach the remote site. And the backups fail for those machines because the tunnel for the backup server isn't up until I go out to a remote machine and ping it from there.
Anyone have a thought on what might be causing this?