Here is the scenario:
A Cisco ASA 5525 running 9.1(5) receives a packet (let's call it packet 'A') on its OUTSIDE interface with a destination address somewhere on its inside network. However, the ASA does not have a route for that specific destination IP address but does have a static route pointing to the OUTSIDE interface. Therefore, packet 'A' is routed to/egresses the OUTSIDE interface. I assume that a "fast-path" connection is now established which includes that routing information.
Soon after, the ASA adds an OSPF-learned route that establishes any IP address on the inside network should be routed to the INSIDE interface on the ASA. The ASA then receives packet 'B' at the OUTSIDE interface. Packet 'B' is identical to packet 'A' (destined for an IP on the inside network), but because of the fast path connection, packet 'B' is routed back out the OUTSIDE interface just like packet 'A.' This happens in spite of the OSPF-learned route which says that packet 'B' should have been sent to the INSIDE interface.
Obviously, this a problem. We replace the OSPF-learned route with an identical static route. Result: no change to the fast path connection. Packets destined to the inside network are still routed back whence they came.
It's not until we explicitly tell the ASA to "clear connection {inside-IP}" that it deletes that fast-path connection and begins routing packets like 'A' and 'B' correctly.
My questions are: why is the Adaptive Security Algorithm working this way? If a fast-path connection is never in danger of timing out due to steady traffic flow, what has to change for that fast-path to be cleared if not a dynamically-learned route?
Best Answer
@legioxi, jwbensley:
I apologize for not having responded earlier. Until today, I didn't realize that anyone had actually responded to my original post. That being said, I finally discovered what was going on:
The Cisco ASA introduced the "timeout floating-conn" command in the 8.2(5)/8.4(2) release which basically tells the ASA how long to keep an established connection even when the ASA knows about other routes. The default is 0:00:00 - meaning those connections NEVER time out.
In Cisco's own words: "When multiple static routes exist to a network with different metrics, the ASA uses the one with the best metric at the time of connection creation. If a better route becomes available, then this timeout lets connections be closed so a connection can be reestablished to use the better route. The default is 0 (the connection never times out). To take advantage of this feature, change the timeout to a new value."
Why the default is 0:00:00 is beyond me. I can understand that low timeout values negate the benefits of fast-path connections in terms of sheer processing, but I would think that the timeout should be set to something and at least give the ASA a chance to adapt to changes in the network or, in the very least, updates in its own configuration made by an administrator.