I think you would have to: - dump the conntrack state - iterate through the dumped state, one at a time, for connections that use the old invalid ip: ---- manually forge and send tcp resets (possibly in both directions?) for all those connections (probably have to write a tiny C or python (scapy) program using a raw socket to spoof the reset for this) ---- then inform conntrack to drop the connection
With a modern kernel and userspace (conntrack tools) this shouldn't be too hard to do. Not sure how easy it would be on OpenWrt, but provided new enough kernel+tools are there it should be the same. Be warned though. Packets matching state INVALID by conntrack *cannot* be safely converted into reset packets, you will end up occasionally resetting valid connections (for example in the presence of extreme packet reordering as often caused by some wireless networks). INVALID state packets have to be dropped. [speaking from personal experience, accepting NEW/RELATED and sending tcp resets for everything else breaks in weird ways] On Tue, Oct 29, 2013 at 11:08 AM, Justin Vallon <[email protected]> wrote: > On 10/29/13, 10:43 AM, Simon Iremonger wrote: >>> >>> Thanks. But somehow, this doesn't seem to work the way I expect it to: >>> - from my local computer (with a 192.168.1.NN address), I ssh into my >>> router and into some remote host. >>> - on the router I do "echo f > /proc/net/nf_conntrack" >>> - result: the ssh connection to the router is immediately cut, but the >>> ssh connection to the remote host is unaffected. >>> I would like (and expected) the exact opposite. >>> What am I missing? >> >> >> Maybe:- >> >> You are missing needed iptables changes to make the "old" forwarded >> connection (which will conntrack as NEW, but not be of type "syn") >> (explicitly of protocol TCP) get "-j REJECT --reject-with TCP-RESET" >> 'ed ? >> >> That way when the local machine sends another packet about this >> connection, it immediately gets, as you say, "cut". > > > The router ssh connection is immediately cut because (I believe) right after > the command is completd (whatever that does), the router tries to > communicate with the outside world, and tries to use an existing connection > that it knows nothing about, so it kills it. The remote connection > (ostensibly going through the router) is not cut, because the connection is > idle, and the router has not yet had a chance to reject anything. > > I think the "REJECT unknown but seemingly established connections" will > still end up waiting for the keep alive timeout to occur. The difference > would be that once the keep-alive is sent, the connection is immediately > torn down (REJECT) vs a timeout (DROP). Thus, it would change from a 2h > (keep-alive) + ~3m (connection timeout) to 2h (keep-alive). > > What you want (I believe) is that for each to-be forgotten connection (from > nf_conntrack), a TCP-RESET is sent (to both sides of the connection), > without needing an incoming packet. As far as I know, that is not > implemented in the kernel in any way. You would have to write a program > that reads nf_conntrack, and spoofs TCP Resets to both ends of the > connection. The public host reset (wan-side) would be lost due to no route, > while the local host reset (internal) would go through. > > Part of the issue here might be to identify "stale" connections. Remembering > the old interface IP would be one way (nuke all connections using > IP=1.2.3.4), but that would require some housekeeping to remember old > interface address(es). Alternately, you could try to identify connections > that are broken - ie: neither src nor dest are local addresses nor > broadcast, etc. > > -- > -Justin > [email protected] > > > > _______________________________________________ > openwrt-users mailing list > [email protected] > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users > _______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
