I am using an IPTables firewall, configured for packet forwarding to a number of servers inside my network.

Iptstate shows a number of connections from a specific IP, all of which have a TTL of more than 120 hours.

1. How can I disconnect the established connections immediately? I have added a drop rule to my firewall for future connections from that IP, but it doesn't disconnect what's already connected.
2. When connecting to a webserver, is it normal to have a 120 hour TTL? Where would that be configured? On the web server, firewall, or the client?

Have you tried restarting the firewall? There should be instructions to flush all existing rules and implement the new ones.

Inserting the DROP rule at the *top* of the chain, like:will filter any packets from the IP, regardless of whether they are of state ESTABLISHED or not. It's normal for the connection to still appear as ESTABLISHED in the state table after you execute a rule such as above - even though no packets from the IP are getting routed. If you don't want to wait for the state table entry to timeout on it's own, you can use a tool such as conntrackd to remove it.

120 hours is normal, AFAICT:The value is given in seconds.

Interesting find that conntrackd! There's also tools like cutter and tcpkill that can help kill TCP sessions.

Out of curiosity, what would null routing the destination do? Is it taken into account quickly by the kernel?

Something like

I guess it doesn't work?

Restarting should be a last resort. I do not want to disconnect valid traffic, just the interesting IPs.

From what I'm reading, is it true that iptstate does not necessarily show the true connections at the given moment?

Restarting the firewall (by this I mean "activating a new iptables configuration") won't disconnect the traffic. The state table entries will still be there when the new firewall config activates, and packets will be able to match the RELATED,ESTABLISHED rule just as before the rules were flushed (as long as the entries haven't timed-out for you or for your peers).

Well, it does what it is meant to do, that is, it shows you the entries in the state table. Whether packets are being actually transfered to and from the IP is a separate issue. For that you'd use something like iptraf.

This raises a couple more questions.

1. WHY does the state remain established, even when the client machine has long before disconnected? What is this purpose?
2. WHY for 120 hours?

Because technically the client didn't disconnect (no TCP connection termination occured), you just inserted a rule to filter all packets from him. Imagine you only wanted to filter packets from the client for 30 seconds, so you execute a DROP rule for the client's IP. 30 seconds later you delete the rule. If the ESTABLISHED state wouldn't still be in the state table, then the client would need to start a new connection.

Not sure why the kernel developers chose 5 days as a timeout value for this. My guess is there might be some sort of anti-DoS considerations but I'm not sure. Maybe someone else can shed some light on this. In any case, even though the 5 days timeout is configured in the kernel source, you can easily change the value on your running box by echoing to /proc or (I would assume) using sysctl. Depending on how much traffic you have you might even get a visible decrease in memory usage.