I'm trying to determine if an application's connection to a database is internal to the application or due to a networking event. This seems like something netfilter would have system-wide visibility on. To that end, I wanted to use -j LOG with iptables to log all TCP resets and timeouts that occur on the system. I don't know what to use for the matching criteria, though.I feel like the answer would involve the conntrack module at some point but I've been able to locate next to nothing on it. The database server is MS-SQL and the J2EE application is running on a RHEL 5.10 VM. The latter is the machine I'm trying to perform the logging on.EDIT:I found this blog post which shows how to log TCP resets (amongst other things) with the --tcp-flags option to iptables. So the outstanding issue is figuring out how to log connections with no explicit RST but are closed due to the connection being seen as stale/timing out.
Can iptables be used to monitor TCP timeouts/resets system-wide?
networking;rhel;iptables;tcp
After asking on IRC a bit, it seems the general expectation is that if one node feels a connection has terminated abnormally for any reason (including reaching an internally derived timeout) it's expected to send the remote node an RST packet before closing the connection on its side. So it appears both questions get answered with the same solution: log TCP resets via --tcp-flags. The basic command to do that on my RHEL 5.10 system (should work on Debian based distros as well) is:root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags RST RST -j LOGroot@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags FIN FIN -j LOGWithout matching criteria, I would probably end up matching quite a few packets, so I created a new rule specifically targeting the system I'm going after:root@xxxxxxvlt01 ~ $ iptables -A OUTPUT  -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags RST RST -j LOGroot@xxxxxxvlt01 ~ $ iptables -A OUTPUT  -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags FIN FIN -j LOGroot@xxxxxxvlt01 ~ $ iptables -nvLChain INPUT (policy ACCEPT 767K packets, 108M bytes) pkts bytes target     prot opt in     out     source               destinationChain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destinationChain OUTPUT (policy ACCEPT 448K packets, 68M bytes) pkts bytes target     prot opt in     out     source               destination    0     0 LOG        tcp  --  *      *       0.0.0.0/0            xxx.xxx.64.248       tcp flags:0x04/0x04 LOG flags 0 level 4    0     0 LOG        tcp  --  *      *       0.0.0.0/0            xxx.xxx.64.248       tcp flags:0x01/0x01 LOG flags 0 level 4root@xxxxxxvlt01 ~ $Which is a lot better. Since my confirmation for the RST-upon-timeout stuff is from someone on IRC I'll leave this open/unanswered in case someone can prove me wrong. After a week I'll accept my own answer on this one unless I'm contradicted.