Running 7.2.4~, we're trying to fail from one interface which has a direct connection to the customer, to a VPN connection over the Internet ... which is the outbound interface. The assumption here was that in using tracking and a higher metric route to the tunnel's end point / gateway ... the PIX would initiate the tunnel and send traffic through it, in the event that the direct connection was down. >From the customer's perspective, when they manually remove their route over >the direct connection, it works. Their gear then brings the traffic over the tunnel it's established and ours responds accordingly. I never have to remove the route over the direct connection. I can only assume this is because of the state of the translation slots in the tunnel and how the PIX works. However, when I try to originate the traffic, the PIX is still trying to send it through the direct interface and not into a tunnel, even though in tracking, it knows the route isn't valid.
I've considered a few workarounds, i.e. having the direct connection as a vpn tunnel as well and just adding a secondary gateway in the even one cannot be reached, and/or NATing their network in one direction (currently, we exempt from both interfaces, which as I've said, works as long as they originate). I've been trying to dig up an "order of operations" on the PIX, to no avail. I would assume that directly connected neighbors take precedence in routing over establishing a VPN connection, but when that neighbor is dead, the next route should come into play. It doesn't seem like rocket science, after all, metric routing is about as basic as it gets ... but still no luck. Has anyone had any success doing something similar or am I violating routing rules on the PIX? Regards, Sean _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
