Cisco Support Community
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

ASA Session setup through wrong interface, session stays there

I have seen an issue with an ASA setting up a connection and keeping this connection through a wrong interface.
ASA is perimeter Firewall, has a default route towards outside and some routes pointing to inside ( and some to a transfer VLAN (
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 | i 6343
UDP outside Transfer, idle 0:00:01, bytes 11494416, flags -
UDP outside Transfer, idle 0:00:01, bytes 13079268, flags -
UDP outside Transfer, idle 0:00:01, bytes 41900464, flags -

I have several devices (,, that try to sent sflow data to a internal station (
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
45 connection(s) deleted.
ASA/pri/act# sh conn address | i 6343
UDP Transfer inside, idle 0:00:00, bytes 536, flags -
UDP outside Transfer, idle 0:00:18, bytes 11500984, flags -
UDP outside Transfer, 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?
Everyone's tags (1)
Super Bronze

Hi, I had this happen to me



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

CreatePlease to create content