ASA Session setup through wrong interface, session stays there

[Jan]

I have seen an issue with an ASA setting up a connection and keeping this connection through a wrong interface.
Background:
ASA is perimeter Firewall, has a default route towards outside and some routes pointing to inside (10.10.0.0) and some to a transfer VLAN (10.16.0.0)
We had to reboot the Coreswitch on the inside thus the inside interface of the ASA was down.
After some time i noticed, that several connections from Transfer networks where not able to conntact my internal networks.

Show of session:

sh conn address 10.10.6.3 | i 6343
UDP outside 10.10.6.3:6343 Transfer 10.16.90.3:1027, idle 0:00:01, bytes 11494416, flags -
UDP outside 10.10.6.3:6343 Transfer 10.16.20.10:1027, idle 0:00:01, bytes 13079268, flags -
UDP outside 10.10.6.3:6343 Transfer 10.16.10.10:1027, idle 0:00:01, bytes 41900464, flags -

I have several devices (10.16.90.3, 10.16.20.10, 10.16.10.10) that try to sent sflow data to a internal station (10.10.6.3).
but instead of sending the session to the inside interface, the data is sent towards outside.

After i clear a connection for one of the addresses, the session is setup correctly and i start receiving sflow again:

ASA/pri/act# clear conn address 10.16.10.10
45 connection(s) deleted.
ASA/pri/act# sh conn address 10.10.6.3 | i 6343
UDP Transfer 10.16.10.10:1027 inside 10.10.6.3:6343, idle 0:00:00, bytes 536, flags -
UDP outside 10.10.6.3:6343 Transfer 10.16.90.3:1027, idle 0:00:18, bytes 11500984, flags -
UDP outside 10.10.6.3:6343 Transfer 10.16.20.10:1027, idle 0:00:04, bytes 13083344, flags -


What has happend (educated guess)
- inside interface of ASA goes down, connected route(s) gets removed
- data arrives for some network which is (unreachable atm) on inside
- default route is used, session is setup through outside
- inside interface comes back, routes appear in routing table
- data arrives for some network which is ( now reachable again) on inside
- uses existing session thus sending to outside instead of inside
- session never expires as data arrives regulary

I noticed only UDP traffic being wrong (sflow, Siemens HiPath CAPWAP,...)
sFlow was not received for about a week and comes back immeadiatly after i clear the connection.

Is this expected behavior? I could imagine that a new/better/other route could/should invalidate existing sessions?

What would be a fix to stop that from happening again?

[Jouni Forss]

Hi,

I had this happen to me some weeks ago when a colleague was replacing some IPS devices connected to a customer ASA firewall.

I would say that the situation is just as you describe. It certainly was in our case. As the physical interface is down the specific route is removed and the default route is used. This in turn builds the xlate which then continues to forward the traffic wrong even though the physical interface has come up. I guess this really only affects UDP traffic as TCP connections would have to be formed again and again if they didnt go through. In our case the customer had problem with the connections from their WLC.

I am not really sure what could be done to correct this. I am wondering if a NAT configuration between INSIDE and TRANSFER would do the trick or would this just be ignored if either of the interfaces were down? If the NAT configuration was matched (even if the traffic is dropped) even though the other interface is down then I guess this should prevent traffic from getting forwarded to external networks.

So maybe a Static Identity NAT from INSIDE to TRANSFER where you essentially configure NAT for the source LAN subnets and NAT them to themselves. This should force traffic coming from TRANSFER towards the LAN subnets to always follow the NAT configurations rather than the routing table.

As I said, I am not sure if the NAT configuration would be ignored if the other interface is down.

- Jouni

EDIT: Typos

[AFL_CCO_TECH]

This may be related to the "timeout floating-conn" setting which now defaults to infinity / 0:00:00 - There is a documentation bug noted under https://bst.cisco.com/bugsearch/bug/CSCtn72626 

Changing the timeout floating-conn to something other than a non-zero setting may resolve the concern and allow connections to be rebuilt on the proper interface as dictated by the routing table.