[c-nsp] Stale tcp connection on FWSM

Tony Varriale tvarriale at comcast.net
Tue Dec 29 19:21:15 EST 2009


Inline...
----- Original Message ----- 
From: "Matthew Melbourne" <matt at melbourne.org.uk>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, December 29, 2009 8:34 AM
Subject: [c-nsp] Stale tcp connection on FWSM


> We have a transparent firewall context on a FWSM (code revision: 3.1(16)).
>
> Recently the number of tcp connections has been increasing to a point 
> where
> it hits the limit defined in the static and new connections are denied.

What type of traffic is this?

> However a "show conn | inc x.x.x.148" doesn't show nearly the number of
> active connections the "show local-host" command might suggest.

These probably won't match.

> A "clear local-host x.x.x.x" fixes the problem temporarily, but the 
> problem
> resurfaces later (and on different hosts).
>Is there any way to see any more
> detail on these 11000+ connections?

What are you looking for?  Typically "sh local host x.x.x.x detail" or "sh 
conn det add x.x.x.x" will some you a little more info including the current 
idle time and timeout.

>
> xxx# sh local-host x.x.x.148 all
> IPv4 local hosts:
> Local host: <x.x.x.148>, tcp conn(s)/limit = 11806/20000,
> embryonic(s)/limit = 4470/50 udp conn(s)/limit = 0/0
>    Xlate(s):
>        Global x.x.x.148 Local x.x.x.148
>
> I am considering whether we should perhaps reduce the default TCP 
> connection
> timeout to less than the default one hour.

What's this box/IP doing that you have 4500 half opens?  Seems like you have 
a broken app or someone is probing you.

For a box that has a static with 20000 conns 50 embryonic is very very low. 
It always depends on the app but those numbers are way too far apart.

I would probably get a real good handle on what your traffic is before you 
do that.  There's shouldn't be 1000s of half opens.  Also, IIRC, embryonics 
are set to time out in 20 seconds.  So, you definitely have some odd stuff 
going on.  If this is valid traffic I'm guessing you are DoSing yourself.

>I am beginning to agree with
> other contributors here, that firewalls placed in front of servers is of
> limited benefit and just creates masses of state which needs to be
> maintained, as well as opening up other potential DoS vectors. :-)

Heh.  It's definitely an interesting conversation for a lot of 
environements.



More information about the cisco-nsp mailing list