How to drop an idle connection with iptables?

DISCUSSION lu zhongda 7 participants 18 messages Nov 23, 2011 – Dec 1, 2011

Share & tools

lu zhongda

author

2011-11-23 10:48 UTC #0 lore raw

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.

Quoted 6 lines

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

Brian J. Murrell

2011-11-23 12:37 UTC #1 lore raw

Quoted 2 lines · lu zhongda

I felt the scenario you described is not really what I want to know.

Probably because your request was unclear.

Quoted 3 lines

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?

Quoted 2 lines

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.

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.

Quoted 10 lines · Brian J. Murrell

Quoted 1 line · lu zhongda
I felt the scenario you described is not really what I want to know.
Probably because your request was unclear.
Quoted 3 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

# 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

Brian J. Murrell

2011-11-24 11:30 UTC #3 lore raw

Quoted 1 line · lu zhongda

Hi Brian:

Hi Lu,

Quoted 2 lines

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.

Quoted 1 line

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

lu zhongda

author

2011-11-25 05:37 UTC #4 lore raw

Hi Brian:

See my comments.

Quoted 8 lines · Brian J. Murrell

Quoted 1 line · lu zhongda
Hi Brian:
Hi Lu,
Quoted 2 lines
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.

Quoted 6 lines

Quoted 1 line
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.

Quoted 7 lines

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.

Quoted 2 lines

b.

Brian J. Murrell

2011-11-25 11:16 UTC #5 lore raw

Quoted 6 lines · lu zhongda

Quoted 4 lines · Brian J. Murrell
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.

lu zhongda

author

2011-11-25 13:45 UTC #6 lore raw

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.

Quoted 22 lines · Brian J. Murrell

Quoted 5 lines · lu zhongda
Quoted 3 lines · Brian J. Murrell
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.

Nikolay Kichukov

2011-11-25 14:20 UTC #7 lore raw

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

Quoted 48 lines · 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.
Quoted 16 lines · Brian J. Murrell
Quoted 5 lines · lu zhongda
Quoted 3 lines · Brian J. Murrell
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.

Quoted 11 lines

Quoted 6 lines
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.
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to [email protected]
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-----

lu zhongda

author

2011-11-26 11:32 UTC #8 lore raw

Hi Nikolay:
Thanks greatly for your information.

Quoted 87 lines · 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
Quoted 48 lines · 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.
Quoted 16 lines · Brian J. Murrell
Quoted 5 lines · lu zhongda
Quoted 3 lines · Brian J. Murrell
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.
Quoted 10 lines
Quoted 6 lines
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.
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to [email protected]
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-----

Anatoly Muliarski

2011-12-01 10:22 UTC #9 lore raw

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.

Signature · 2 lines

Best regards
Anatoly Muliarski

Jan Engelhardt

2011-12-01 10:39 UTC #10 lore raw

Quoted 5 lines · 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

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

John Haxby

2011-11-25 20:01 UTC #11 lore raw

In reply to lu zhongda

Quoted 9 lines · lu zhongda

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

lu zhongda

author

2011-11-26 11:30 UTC #12 lore raw

John:
Thanks greatly for your suggest.

Quoted 27 lines · John Haxby

Quoted 9 lines · lu zhongda
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

Gao feng

2011-11-25 01:14 UTC #13 lore raw

In reply to lu zhongda

Quoted 3 lines · 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

lu zhongda

author

2011-11-25 03:40 UTC #14 lore raw

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.

Quoted 8 lines · Gao feng

Quoted 3 lines · 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

-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

lu zhongda

author

2011-11-25 03:41 UTC #15 lore raw

In reply to Gao feng

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.

Quoted 8 lines · Gao feng

Quoted 3 lines · 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

lu zhongda

author

2011-11-25 03:59 UTC #16 lore raw

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?

Quoted 61 lines · lu zhongda

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.
Quoted 11 lines · Gao feng
Quoted 6 lines · 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

Gao feng

2011-11-25 05:39 UTC #17 lore raw

In reply to lu zhongda

Quoted 2 lines · 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.