Route 0/0 tunneled perculiar behavoiur on SSL VPN Asa

[lim.jltech@hotmail.com]

Greetings venerable mighty Asa legends,If i may come by in search of your wisdom.

We have SSL VPN ASA for our Anyconnect clients. All system is go and things work just fine, bar one perculiar random behaviour that manifests in uncertain periods.

The setup is as plain as can be,

We only have 3 interfaces confugred, namely :

Managment

Outside &

Inside.

We have the standard route 0/0 outisde

We also have per the practice of ssl vpn firewall the static route  0/0 tunneled inside.

Finally, we also have specific static routes for the servers users need to reach. (they are different from the next hop value specified on the route 0/0 tunneled)

So users connect and are happilly establshed with tcp on their Sap clients called SapGui.

Occasionally & frequently for SapGui users, if leaving their clients idle for several minutes, they will received a disconnect.

We initially blamed servers' tcp timers but this was finally exonerated. After much more scouting, we actually observed clients actually taking the route 0/0 tunneled path and naturally getting a reset because of deny as it doesnt have a tcp session(rather than the specific routes specified and also originally used when clients first successfully complete handshakes)

We brought the ASA to 9.18.55 and gave her a proper reboot with hopes to clear out what I imagine to to a leaky memory maybe(?)

Anyone seen or heard anything in this vein before?

Your input is highly valued gents.

[marce1000]

 - Review this document : https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116312-qanda-anyconnect-00.html
               You may also find this bug report informational : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsl52873

 M.

[tvotna]

If traffic takes tunneled default route while specific routes present in the routing table, then this is a bug. E.g. CSCvs59056, but description doesn't match yours exactly. If upgrade doesn't help, you need to open a TAC case. Another good idea is to collect packet capture with "trace" option on ASA and reproduce the issue (as the number of trace buffers is very limited, you need to leave connection idle, then enable capture and then immediately send a packet which leads to conn drop). Hopefully this will help understand why connection is dropped if ASA sends RST.

[lim.jltech@hotmail.com]

Thnaks Marce for the train of thought, I shall then also review the good documents you've kindly shared.

tvotna, those are great angles and yes  we have gone down that road too with some captures in attempts to delineate the symptoms.

Here's what's happening on the wires :
User logs on the Sap gui Client and successfully access the target server ( by virture of specific static route );
then while working on the Sapgui, they randomly get thrown off with broken connection message.

This is because the SSL VPN firewall routes it to the default 0/0 tunneled static route ( instead of taking the preffered specific static route which in the first place worked and allowed the tcp session establishment), 
then the default static hop which knows naught of the already established tcp session in the beginning will deny the packet and curtly sent a reset to the client causing the broken connection experince.

The only peculiarity of a faulting packet that (may ) trigger it has a PSH flag flipped on the tcp_options, 

I strangely think that my ASA has trouble differentiating packets, but let me try the raw type capture as you've kinldy shared

With much thanks as always