Deny TCP (no connection) dan Teardown TCP connection ON ASA 5510, HELP PLZ

[erwinerwinerwin]

im currently implementing IPS using AIP-SSM-10 with ASA 5510, and i have problem with ASA, with currently disabled IPS function, i keep received complain about blocked/slowed connection to oracle server, using port 8000 from remote-office host, i traced with syslog and received large number message related with the oracle server IP address.

diagram of the network is bit like this:

________ ________ _____________

|oracle| |switch| |ASA 5510 |

|server|----|______|----|transparent|

-------- -------------

192.168.10.206 |

|

|

-------------

| ROUTER |

|___________|

|

________ -------------

| REMOTE | ------ | Router |

| USER | -------------

----------

192.168.5.x

and the syslog message sounds like:

302013: Built inbound TCP connection 1662347 for OUTSIDE:192.168.5.52/1311 (192.168.5.52/1311) to inside:192.168.10.206/8000 (192.168.10.206/8000)

302014: Teardown TCP connection 1662345 for OUTSIDE:192.168.5.52/1310 to inside:192.168.10.206/8000 duration 0:00:00 bytes 542 TCP FINs

302013: Built inbound TCP connection 1662345 for OUTSIDE:192.168.5.52/1310 (192.168.5.52/1310) to inside:192.168.10.206/8000 (192.168.10.206/8000)

302014: Teardown TCP connection 1662343 for OUTSIDE:192.168.5.52/1309 to inside:192.168.10.206/8000 duration 0:00:00 bytes 539 TCP FINs

302013: Built inbound TCP connection 1662343 for OUTSIDE:192.168.5.52/1309 (192.168.5.52/1309) to inside:192.168.10.206/8000 (192.168.10.206/8000)

106015: Deny TCP (no connection) from 192.168.5.52/1302 to 192.168.10.206/8000 flags FIN ACK on interface OUTSIDE

302014: Teardown TCP connection 1662338 for OUTSIDE:192.168.5.52/1308 to inside:192.168.10.206/8000 duration 0:00:00 bytes 538 TCP FINs

106015: Deny TCP (no connection) from 192.168.5.52/1301 to 192.168.10.206/8000 flags FIN ACK on interface OUTSIDE

106015: Deny TCP (no connection) from 192.168.5.52/1298 to 192.168.10.206/8000 flags FIN ACK on interface OUTSIDE

106015: Deny TCP (no connection) from 192.168.5.52/1303 to 192.168.10.206/8000 flags FIN ACK on interface OUTSIDE

can anybody help me, cause i'm completely stuck on this problem...

thank you.

[gfullage]

You're in luck, I saw this at a customer just recently. You're probably hitting bug CSCsd00175 (see http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsd00175&Submit=Search for details).

Try adding the "sysopt" workaround as listed and see if it resolves your issue.

Basically with the small added latency of having the IPS inline, the PIX clears its connection too quickly upon seeing the initial FIN from the server, and when the response comes back from the client (the FIN ACK) it is not allowed through as there is no connection for it anymore. These connections don't get cleared down properly and they build up, causing slow or no response from the server.

You can see those last three syslogs are the FIN ACK's from the client not making it to the server. You should be able to do a "netstat -an" and see all these connections building up in LAST-ACK state (or something like that, can't remember the actual name of it).

[erwinerwinerwin]

I see it, but it's a different case,

application that's running is an oracle, with port 8000

and i'm using asa version 7.1(1)

but, the teardown process were alike, but mine are oracle instead not ftp.

[gfullage]

The bug mentions FTP but it's any TCP based protocol. My customer was seeing it on Oracle also running on the standard Oracle ports. And they were running 7.1(1).

FYI, the "First-Found-In-Version", if that's why you think you're not hitting this, is simply what it states, the first version of code that we saw this bug in. The bug will then be in all versions of code up to the "First-Fixed-In-Version(s)". In this case it is 7.1(1.1), which is later than 7.1(1) and therefore the code you're running has the bug in it.

Try the workaround, it's one simple command, and see if it resolves your problem.

[erwinerwinerwin]

i've your sugestion, but it didn't fix the problem completely, it's because my connection time is more than 15 second, so the ' sysopt connetion timewait' command doesn't solve it completely, i still have to reset the connection when it's teared down.

but at least no complain again from the customer.

when did the patch released?

[gfullage · Accepted solution]

7.1(2), which contains the fix for this, is already posted at http://www.cisco.com/cgi-bin/tablebuild.pl/pix.

If the workaround works for you though, and you're not hitting any other problems, then I'd probably recommend you just stay on that version, but I'll leave it up to you.