2

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?

5
  • Can you post the output of packet-tracer using that destination IP after the route change? cisco-help.org/2011/06/asa-firewall-packet-tracer-command.html – some_guy_long_gone Jul 8 '14 at 20:56
  • Also what ASA version are you running and what is the exact command you use to clear the connection? clear connection is not a valid command on my ASA with 9.2. – some_guy_long_gone Jul 8 '14 at 20:57
  • In your opening statement you said A Cisco ASA receives 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 – jwbensley Jul 17 '14 at 12:42
  • At this point you have a routing loop. If traffic comes in the outside interface that is because the layer 3 device attached thinks the destination IP subnet is reachable via the interface it has facing the ASA. If the ASA disagrees and sends the packet back...Boom! Routing loop. – jwbensley Jul 17 '14 at 12:42
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 21:23
3

@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.

1
  • Thanks for the update and filling in a solution to the problem. – some_guy_long_gone Jul 18 '14 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.