Re: How to drop an idle connection with iptables?

[lu zhongda <luzhongda@gmail.com>]

Hi Nikolay:
     Thanks greatly for your information.

On 2011-11-25 22:20, Nikolay Kichukov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> just googled what you're after and bumped to:
>
> http://www.lowth.com/cutter/
>
> HTH
>
> P.S. Our Sonicwall devices have that feature to close established connections when they hit a predefined timeout value
> with no data passing through.
>
> - -Nik
>
> On 11/25/2011 03:45 PM, lu zhongda wrote:
>> Hi Brian:
>> We supply java application server product to our customer.
>>      The application server supplies jdbc connection pool functionality to deployed web application.
>>      The jdbc connection pool usually keeps a fixed count of physical connections to database which are socket connections.
>>      The support staff reflected that the connections in the connection pool were dropped by firewall after 30mins to
>> become idle under customer environment .
>>      I can't get clear information whether the firewall product is iptables.
>>
>>      I googled the topic "firewall drop idle connection" on the Internet, found somebody met the same issue like me even
>> though they used the firewall product of cisco
>>      such as:
>> http://vivekagarwal.wordpress.com/2009/07/04/firewall-dropping-oracle-database-connections-in-websphere-connection-pool/
>>
>>      Even some web page indicated that iptables can drop idle connection, such as the tcp section of
>>
>> http://www.rigacci.org/wiki/lib/exe/fetch.php/doc/appunti/linux/sa/iptables/conntrack.html
>>
>>
>>      I am familiar with Linux, so i want to reproduce the issue with iptables, this is why i posed this topic, I want to
>> know whether iptables support this or not.
>>      If yes, what is the detailed rule set, if not then that is.
>>
>>      As to whether iptables should support this feature, it seems that some product supported this, such as pfsense on
>> freebsd or some commercial product.
>>      Because I never touch freebsd, so I don't want to use pfsense . From my opinion closing the idle connection can
>> avoid the upper application leak idle connection,
>>      releasing unused system socket resource. So it is a useful feature if iptables can support this.
>>
>>      This is the background for my question and is my real-world use case, haw-haw.
>>      Thanks for your help and hope for your answer.
>>
>> On 2011-11-25 19:16, Brian J. Murrell wrote:
>>> On 11-11-25 12:37 AM, lu zhongda wrote:
>>>> On 2011-11-24 19:30, Brian J. Murrell wrote:
>>>>> You didn't answer my other question though, which is why do you think
>>>>> you need to be dropping idle, yet still ESTABLISHED sessions (and
>>>>> breaking higher level protocols when you do that)?
>>>> The need to drop idle connection comes from one technical support request:
>>> Answering my question of "why do you want to do this" with "because
>>> somebody asked" does not really answer the question though.
>>>
>>> There is an important reason for me to to ask and you to answer the
>>> question (i.e. with a real-world use-case) and that's because typically
>>> when somebody is proposing to do things that are "strange" or "not as
>>> intended" (and indeed which will result in other things breaking -- like
>>> TCP in this case) it's because they are trying to solve a problem with
>>> the wrong tool.
>>>
>>> Can you please provide a real-world use-case as to why you'd want/need
>>> to stop (i.e. break) an open TCP session?
>>>
>>> Cheers,
>>> b.
>>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOz6QfAAoJEDFLYVOGGjgXuiIIAOPlQpEkbvo3l2CFPOZ8Y1P3
> DIqWsBsImFwGq3/xAk8Poypsz3ZLN+dzsGdGmBHVVF8mzTJO4bn33yEmIYj7wXPC
> +8zuKHBiXXXrguS/nZq3Xr19KoWGTDvBa/HanO3q5uq7mJaMETo484jf2uHYZbCS
> ms4pd0BvKGGMhu5r781hcRdUU2ZXmsm8LmVyfKYDUkGrgLqQrJGrcs+s6KMDe89p
> vU+/6rdXnDfVjhIasKZshuiwTbhTcKEULpVot+oiJLQ5uT7ova4yXL6AP626wO4c
> FHfeK8RfBImQLgDRWOx5GPcdEPFt06sBwPEcJJUdcleW8Vy5xYiUFAZZSpFFIhY=
> =LG4G
> -----END PGP SIGNATURE-----
>