[clue-tech] Making linux netfilter ip_conntrack forget an entry?

[Jim Ockers]

Hi everyone,

As you may know the Linux kernel's netfilter code maintains a
connection list in /proc/net/ip_conntrack (probably the ip_conntrack.o
kernel module does this).

This is handy because you can specify a rule like this in iptables:

iptables -t filter -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

Then the conntrack module can check if a packet matches an existing
connection, and iptables will allow it if it does.

However we have a situation where we have an interface which may
have an access level change, depending on a business requirement that
they pay for access.  Does anyone know how to make conntrack forget an
individual connection that's masqueraded?

Suppose we have a customer A which was connected to commport /dev/ttyS8, 
and customer A was paying for full internet access on day 1.

On day 2, customer A decides they don't want to pay for full internet
access anymore.  We want to disable their port's internet access
privilege without breaking the local networking functions that they
use for the rest of our multipurpose system.

So we remove the general ACCEPT for their commport's internet
traffic and replace it with a REJECT.  However the RELATED,ESTABLISHED
rule is still present because we have to be sure we don't break something
important that they might be doing on the local network.

What we found is that existing connections such as a GRE protocol VPN,
a large file download over HTTP, a HTTP connection that is Keep-Alive,
etc. still match the RELATED,ESTABLISHED even if new sockets would 
be REJECTed.

We don't want to down the interface (kill pppd) because that
could disrupt something else.  It'd be most convenient if we could
delete entries from /proc/net/ip_conntrack, so the kernel would "forget"
about packets that are no longer allowed (so they don't match
RELATED,ESTABLISHED).

Does anyone know how to make conntrack forget a masqueraded socket?

We've thought about parsing /proc/net/ip_conntrack to identify tcp
sockets that need to be killed, and using a program like cutter
(http://www.lowth.com/cutter) to kill them.  This wouldn't work for
any non-TCP protocol (GRE, UDP, ...).

Thanks for any ideas,
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/