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]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
