Re: How to drop an idle connection with iptables?

Re: How to drop an idle connection with iptables?

[lu zhongda]

Hi Lloyd Standish:
     Thanks for your feedback greatly.
     I felt the scenario you described is not really what I want to know.

     I want to know if there is any way to set up iptables so
     that it will drop a connection after that connection has been idle 
for a specified period of time?

    I have tried connection tracking function of iptables, however it 
seems not work for my case.
    I wonder whether there are some other means to achieve this.
    Thanks.

    Best Regards.

 > Follows:
 >      Does anyone know about how to drop an idle connection when timeouts?
 >      Thanks for any feedback in advance.
 > Best Regards.
 > Lu Zhongda
 >

+ I think you are referring to what is called "dead gateway detection."  
There are patches for current kernels to allow netfilter to do this 
(http://www.ssi.bg/~ja/#routes).

Re: How to drop an idle connection with iptables?

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On 11-11-23 05:48 AM, lu zhongda wrote:
> 
>     I felt the scenario you described is not really what I want to know.

Probably because your request was unclear.

>     I want to know if there is any way to set up iptables so
>     that it will drop a connection after that connection has been idle
> for a specified period of time?

Define "drop", "connection" and "idle".  And why do you feel you need to
"drop" them?

>    I have tried connection tracking function of iptables, however it
> seems not work for my case.

Please explain why it doesn't.  What are you trying to achieve exactly?
 Perhaps a real-world use-case might help us understand.

b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: How to drop an idle connection with iptables?

[lu zhongda]

[-- Attachment #1: Type: text/plain, Size: 2991 bytes --]

Hi Brian:
     First very sorry for confusion, I will explain it in details.
     My question is:
     " Is it possible to configure iptables to monitor activity on 
socket connections, then close or block connections that haven't had any 
activity for a specified amount of time?"

     As to the individual terms, I define them as follows:
     Connection: Socket tcp connection
     Idle:socket connections haven't had any activity for a specified 
amount of time, for example after connection established, data is 
transmitted through connection in big time intervals.
     Drop:  block and discarded the packets between two endpoints of a 
connection or just close the connection

     At least, I hope iptables can confirm whether a connection is idle 
or not by its rules, this is the key point of my problem.
     I have used conntrack of iptables, it seems not work.

     My rules for conntrack to trace and drop idle connection is:
iptables -AINPUT     -p tcp -m state --stateESTABLISHED-j ACCEPT
     iptables -AOUTPUT-p tcp -m state --stateNEW,ESTABLISHED-j ACCEPT
iptables -AINPUT-p tcp ! --syn -m state --stateNEW-j DROP

     I think from conntrack's perspective, a connection is idle once the 
ESTABLISHED typed item in //proc/net/ip_conntrack///is removed after the 
timeout interval of the item.
     The timeout is defined in 
//proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/ , 
which is defaulted to 5 days, I change it to a short value for testing, 
such as 1 min.
     the linux shell command is: echo "60" > 
//proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/
     The timeout for ESTABLISHED type item does works, and the item is 
removed after timeout, however the connection is not blocked or dropped 
at all.

     I used a simple echo alike client-server program to test.  The 
client sends a text message to the server, the server echo the message 
back to the client.
    The socket channel between two sides is kept alive. The listening 
port for server is 9999.

     My environment is:
     OS:  Redhat enterprise linux 5.2, kernel version 2.6.18
     Iptables: v1.3.5

     I attached my rules in /etc/sysconfig/iptables for reference, hope 
it can help.
     Thanks for your continuous help.

On 2011-11-23 20:37, Brian J. Murrell wrote:
> On 11-11-23 05:48 AM, lu zhongda wrote:
>>      I felt the scenario you described is not really what I want to know.
> Probably because your request was unclear.
>
>>      I want to know if there is any way to set up iptables so
>>      that it will drop a connection after that connection has been idle
>> for a specified period of time?
> Define "drop", "connection" and "idle".  And why do you feel you need to
> "drop" them?
>
>>     I have tried connection tracking function of iptables, however it
>> seems not work for my case.
> Please explain why it doesn't.  What are you trying to achieve exactly?
>   Perhaps a real-world use-case might help us understand.
>
> b.
>


[-- Attachment #2: iptables --]
[-- Type: text/plain, Size: 1492 bytes --]

# Generated by iptables-save v1.3.5 on Thu Nov 24 15:19:59 2011
*filter
:INPUT DROP [200:29532]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 9999::" 
-A INPUT -p tcp -m tcp --dport 9999 -j ACCEPT 
-A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix "conn established::" 
-A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "DROP invalid::" 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 -m state --state NEW -m recent --set --name DEFAULT --rsource 
-A INPUT -i eth0 -p tcp -m tcp --dport 9999 -m state --state NEW -m recent --update --seconds 600 --hitcount 2 --name DEFAULT --rsource -j DROP 
-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 9999 -j ACCEPT 
-A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j LOG --log-prefix "out conn established::" 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
COMMIT
# Completed on Thu Nov 24 15:19:59 2011

Re: How to drop an idle connection with iptables?

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On 11-11-24 04:46 AM, lu zhongda wrote:
> Hi Brian:

Hi Lu,

>     At least, I hope iptables can confirm whether a connection is idle
> or not by its rules, this is the key point of my problem.

Perhaps there is a module which can do this but perhaps not because what
you are proposing will actually break protocols based on TCP.

>     I have used conntrack of iptables, it seems not work.

iptables' conntrack works exactly as it should.  When it sees a TCP
session go to ESTABLISHED (i.e. TCP 3-way handshake is completed) it
allows packets on that session and continues to do so until the session
is destroyed with FIN and/or RST packets.

To start dropping/rejecting packets before that TCP session is shutdown
will break the protocol that is running on the socket because it expects
the session to still be open.

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)?

b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: How to drop an idle connection with iptables?

[lu zhongda]

Hi Brian:

See my comments.

On 2011-11-24 19:30, Brian J. Murrell wrote:
> On 11-11-24 04:46 AM, lu zhongda wrote:
>> Hi Brian:
> Hi Lu,
>
>>      At least, I hope iptables can confirm whether a connection is idle
>> or not by its rules, this is the key point of my problem.
> Perhaps there is a module which can do this but perhaps not because what
> you are proposing will actually break protocols based on TCP.
Agreed.


>>      I have used conntrack of iptables, it seems not work.
> iptables' conntrack works exactly as it should.  When it sees a TCP
> session go to ESTABLISHED (i.e. TCP 3-way handshake is completed) it
> allows packets on that session and continues to do so until the session
> is destroyed with FIN and/or RST packets.
>
> To start dropping/rejecting packets before that TCP session is shutdown
> will break the protocol that is running on the socket because it expects
> the session to still be open.
>
> 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:
I need to confirm whether iptables can drop idle connection just like 
some other commercial products can do.
I need to confirm whether iptables can do it， if it can ,what is the 
rule set.
If not then that is. I have no strong appeal that it can do it.
Thanks for your feedback.
> b.
>

Re: How to drop an idle connection with iptables?

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: How to drop an idle connection with iptables?

[lu zhongda]

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.
>

Re: How to drop an idle connection with iptables?

[Nikolay Kichukov]

-----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-----

Re: How to drop an idle connection with iptables?

[lu zhongda]

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-----
>

Re: How to drop an idle connection with iptables?

[Anatoly Muliarski]

Hi Lu,

I suggest trying to drop invalid packets:
iptables -I INPUT -m state --state INVALID -j DROP
iptables -I OUTPUT -m state --state INVALID -j DROP

Using with echo 0 >
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose and little
connection timeout may solve your problem.

-- 
Best regards
Anatoly Muliarski

Re: How to drop an idle connection with iptables?

[Jan Engelhardt]

On Thursday 2011-12-01 11:22, Anatoly Muliarski wrote:

>Hi Lu,
>
>I suggest trying to drop invalid packets:
>iptables -I INPUT -m state --state INVALID -j DROP
>iptables -I OUTPUT -m state --state INVALID -j DROP

Or better yet, -m conntrack --ctstate INVALID.

Re: How to drop an idle connection with iptables?

[John Haxby]

On 25 Nov 2011, at 13:45, lu zhongda wrote:

> 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.


This is quite common.

A lot of home routers (certainly the Netgear ones) use iptables and will
drop idle connections after some configurable time.  Cisco routers that
track connections (for NAT or otherwise) will typically drop idle
connections after some configurable interval (I think the first time I
came across this in about 2001 it was 30 minutes).

If you're affected by this then you need something that will keep the
connection alive.   In your case you need a no-op to keep the connection
alive.  Either that or drop your idle connections before the router does
it for you.

jch

Re: How to drop an idle connection with iptables?

[lu zhongda]

John:
     Thanks greatly for your suggest.

On 2011-11-26 4:01, John Haxby wrote:
> On 25 Nov 2011, at 13:45, lu zhongda wrote:
>
>> 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.
>
> This is quite common.
>
> A lot of home routers (certainly the Netgear ones) use iptables and will
> drop idle connections after some configurable time.  Cisco routers that
> track connections (for NAT or otherwise) will typically drop idle
> connections after some configurable interval (I think the first time I
> came across this in about 2001 it was 30 minutes).
>
> If you're affected by this then you need something that will keep the
> connection alive.   In your case you need a no-op to keep the connection
> alive.  Either that or drop your idle connections before the router does
> it for you.
>
> jch
>

Re: How to drop an idle connection with iptables?

[Gao feng]

于 2011年11月24日 17:46, lu zhongda 写道:
>     The timeout is defined in //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/ , which is defaulted to 5 days, I change it to a short value for testing, such as 1 min.
>     the linux shell command is: echo "60" > //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/
>     The timeout for ESTABLISHED type item does works, and the item is removed after timeout, however the connection is not blocked or dropped at all.

Hi zhongda.

How about echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose

Re: How to drop an idle connection with iptables?

[lu zhongda]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

Hi, Gao Feng:
     First thanks for your response!
     I set the two timeout to their corresponding value:
     echo 60 > 
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
     echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose

     The ESTABLISHED item for port 9999 was inserted after connection 
created and removed after 60 seconds timeout.
     Using tool conntrack supplied by iptables also proved this:

     conntrack -E
     [DESTROY] tcp      6 src=192.168.2.194 dst=192.168.2.166 
sport=41570 dport=9999 packets=4 bytes=218 src=192.168.2.166 
dst=192.168.2.194 sport=9999         dport=41570 packets=3 bytes=166

     However netstat indicated that the physical connection was still 
there and the communication between two endpoints was not blocked or 
dropped.

     netstat -an | grep 9999
     tcp        0      0 192.168.2.166:9999          
192.168.2.194:41570         ESTABLISHED

     The state related rule set in my configuration did not work at all:

     -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
     -A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix 
"conn established::"
     -A INPUT -p tcp -m state --state INVALID -j DROP
     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
--state NEW -j LOG --log-prefix "DROP invalid::"
     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
--state NEW -j DROP

     The communication was not affected by the rules and no log in 
/var/log/iptables.log.
     For an explanation, I redirected my Linux kernel log to 
/var/log/iptables.log

     However other rule in /etc/sysconfig/iptables did logged file, log 
found in /var/log/iptables.log
     -A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 
9999::"

     I attached my iptables rule set for reference.
     Hope you can give me another hint and related rule set.
     Thanks for your support.

On 2011-11-25 9:14, Gao feng wrote:
> 于 2011年11月24日 17:46, lu zhongda 写道:
>>      The timeout is defined in //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/ , which is defaulted to 5 days, I change it to a short value for testing, such as 1 min.
>>      the linux shell command is: echo "60">  //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/
>>      The timeout for ESTABLISHED type item does works, and the item is removed after timeout, however the connection is not blocked or dropped at all.
> Hi zhongda.
>
> How about echo 0>  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
>


[-- Attachment #2: iptables --]
[-- Type: text/plain, Size: 1145 bytes --]

# Generated by iptables-save v1.3.5 on Thu Nov 24 15:19:59 2011
*filter
:INPUT DROP [200:29532]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 9999::" 
-A INPUT -p tcp -m tcp --dport 9999 -j ACCEPT 
-A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix "conn established::" 
-A INPUT -p tcp -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "DROP invalid::" 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 

-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 9999 -j ACCEPT 
-A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j LOG --log-prefix "out conn established::" 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
COMMIT
# Completed on Thu Nov 24 15:19:59 2011

Re: How to drop an idle connection with iptables?

[lu zhongda]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

Hi, Gao Feng:
     First thanks for your response!
     I set the two timeout to their corresponding value:
     echo 60 > 
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
     echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose

     The ESTABLISHED item for port 9999 was inserted after connection 
created and removed after 60 seconds timeout.
     Using tool conntrack supplied by iptables also proved this:

     conntrack -E
     [DESTROY] tcp      6 src=192.168.2.194 dst=192.168.2.166 
sport=41570 dport=9999 packets=4 bytes=218 src=192.168.2.166 
dst=192.168.2.194 sport=9999         dport=41570 packets=3 bytes=166

     However netstat indicated that the physical connection was still 
there and the communication between two endpoints was not blocked or 
dropped.

     netstat -an | grep 9999
     tcp        0      0 192.168.2.166:9999          
192.168.2.194:41570         ESTABLISHED

     The state related rule set in my configuration did not work at all:

     -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
     -A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix 
"conn established::"
     -A INPUT -p tcp -m state --state INVALID -j DROP
     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
--state NEW -j LOG --log-prefix "DROP invalid::"
     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
--state NEW -j DROP

     The communication was not affected by the rules and no log in 
/var/log/iptables.log.
     For an explanation, I redirected my Linux kernel log to 
/var/log/iptables.log

     However other rule in /etc/sysconfig/iptables did logged file, log 
found in /var/log/iptables.log
     -A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 
9999::"

     I attached my iptables rule set for reference.
     Hope you can give me another hint and related rule set.
     Thanks for your support.


On 2011-11-25 9:14, Gao feng wrote:
> 于 2011年11月24日 17:46, lu zhongda 写道:
>>      The timeout is defined in //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/ , which is defaulted to 5 days, I change it to a short value for testing, such as 1 min.
>>      the linux shell command is: echo "60">  //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/
>>      The timeout for ESTABLISHED type item does works, and the item is removed after timeout, however the connection is not blocked or dropped at all.
> Hi zhongda.
>
> How about echo 0>  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
>


[-- Attachment #2: iptables --]
[-- Type: text/plain, Size: 1145 bytes --]

# Generated by iptables-save v1.3.5 on Thu Nov 24 15:19:59 2011
*filter
:INPUT DROP [200:29532]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 9999::" 
-A INPUT -p tcp -m tcp --dport 9999 -j ACCEPT 
-A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix "conn established::" 
-A INPUT -p tcp -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "DROP invalid::" 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 

-A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT 
-A OUTPUT -p tcp -m tcp --sport 9999 -j ACCEPT 
-A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j LOG --log-prefix "out conn established::" 
-A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT 
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
COMMIT
# Completed on Thu Nov 24 15:19:59 2011

Re: How to drop an idle connection with iptables?

[lu zhongda]

And the following document for conntrack-tool all talked about:
"established TCP connections can be cut or blocked by removed entrance 
in /proc/net/ip_conntrack"

http://conntrack-tools.netfilter.org/about.html
http://conntrack-tools.netfilter.org/manual.html

However I removed the entrance by timeout or manually by conntrack -D, 
none worked.

I am just wondering whether conntrack only works for tracing event, no 
functionality for filtering at all?


On 2011-11-25 11:41, lu zhongda wrote:
> Hi, Gao Feng:
>     First thanks for your response!
>     I set the two timeout to their corresponding value:
>     echo 60 > 
> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
>     echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
>
>     The ESTABLISHED item for port 9999 was inserted after connection 
> created and removed after 60 seconds timeout.
>     Using tool conntrack supplied by iptables also proved this:
>
>     conntrack -E
>     [DESTROY] tcp      6 src=192.168.2.194 dst=192.168.2.166 
> sport=41570 dport=9999 packets=4 bytes=218 src=192.168.2.166 
> dst=192.168.2.194 sport=9999         dport=41570 packets=3 bytes=166
>
>     However netstat indicated that the physical connection was still 
> there and the communication between two endpoints was not blocked or 
> dropped.
>
>     netstat -an | grep 9999
>     tcp        0      0 192.168.2.166:9999          
> 192.168.2.194:41570         ESTABLISHED
>
>     The state related rule set in my configuration did not work at all:
>
>     -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
>     -A INPUT -p tcp -m state --state ESTABLISHED -j LOG --log-prefix 
> "conn established::"
>     -A INPUT -p tcp -m state --state INVALID -j DROP
>     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
> --state NEW -j LOG --log-prefix "DROP invalid::"
>     -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state 
> --state NEW -j DROP
>
>     The communication was not affected by the rules and no log in 
> /var/log/iptables.log.
>     For an explanation, I redirected my Linux kernel log to 
> /var/log/iptables.log
>
>     However other rule in /etc/sysconfig/iptables did logged file, log 
> found in /var/log/iptables.log
>     -A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 
> 9999::"
>
>     I attached my iptables rule set for reference.
>     Hope you can give me another hint and related rule set.
>     Thanks for your support.
>
>
> On 2011-11-25 9:14, Gao feng wrote:
>> 于 2011年11月24日 17:46, lu zhongda 写道:
>>>      The timeout is defined in 
>>> //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/ 
>>> , which is defaulted to 5 days, I change it to a short value for 
>>> testing, such as 1 min.
>>>      the linux shell command is: echo "60">  
>>> //proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established/
>>>      The timeout for ESTABLISHED type item does works, and the item 
>>> is removed after timeout, however the connection is not blocked or 
>>> dropped at all.
>> Hi zhongda.
>>
>> How about echo 0>  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
>>
>

Re: How to drop an idle connection with iptables?

[Gao feng]

于 2011年11月25日 11:41, lu zhongda 写道:
>     However other rule in /etc/sysconfig/iptables did logged file, log found in /var/log/iptables.log
>     -A INPUT -p tcp -m tcp --dport 9999 -j LOG --log-prefix "ACCEPT 9999::"

hi zhongda.
Because -m state is based on the ip_conntrack.when ip_conntrack destroy,the -m state will never match.

How to drop an idle connection with iptables?

[陆仲达]

Follows:
     Does anyone know about how to drop an idle connection when timeouts?
     Thanks for any feedback in advance.
Best Regards. 
Lu Zhongda

Re: How to drop an idle connection with iptables?

[Lloyd Standish]

On Tue, 22 Nov 2011 06:22:56 -0600, 陆仲达 <zhongda.lu@dev.bessystem.com> wrote:

> Follows:
>      Does anyone know about how to drop an idle connection when timeouts?
>      Thanks for any feedback in advance.
> Best Regards.
> Lu Zhongda
>

I think you are referring to what is called "dead gateway detection."  There are patches for current kernels to allow netfilter to do this (http://www.ssi.bg/~ja/#routes).

I think these patches allow the kernel to determine when the nexthop router is down, but I don't think they will detect failure beyond that (several hops out).  However, I did not try the patches.

In my investigation of the alternatives for detecting a bad uplink and adjusting the routing accordingly, I found an open source program, lsm (Link Status Monitor, http://lsm.foobar.fi/), which actually does configurable ping traffic analysis (to any IP) to determine when an uplink should be removed or replaced.  I am not sure, but I think this level of control is not available through the kernel patches linked to above.

lsm detects failed links and executes an user-supplied script on each failure or recovery event, passing parameters with info on which interface was involved and whether it is "up" or "down".  You can rewrite your firewall script to accept these lsm-supplied parameters to readjust any load-balancing routing, send emails to announce the event, etc.  This will become clear when you check out the lsm package.

If more than one interface may be down at the same time (which is my case), the "state" of the interfaces will need to be saved.  This is because lsm only notifies when a single link changes.  I suggest using a bit field saved to a file, using bit-wise operators.  That's what I did, using bash.

(Since lsm keeps state information about all the monitored links, it would be interesting to modify lsm to pass a "state" bitfield as one of the parameters upon every state change.)

Good luck!