TPROXY and original dest address question
Thu, 28 Mar 2002 17:55:25 +0100
Balazs Scheidler wrote:
> because we don't do full TCP tracking, and our NAT is quite limited. (only
> DNAT, and only to local IP stack). And in addition entries are not
> timeouted from the table.
> a new entry is added to this table when
> 1) a TPROXY destination is encountered
> 2) when a socket is 'bound' to a foreign address (either for listening and
> an entry is removed from this table when
> 1) the socket associated with the entry is destroyed (iff a socket is
> associated with an entry)
Ok. So there is integration between the tproxy table and the host IP stack
somehow, to keep the TPROXY table in sync with the host IP stack. Nice. Kind
of missing in conntrack..
> 2) when a TCP rst is returned by the stack (happens only when a socket is
> not yet associated)
Why this? And doesn't it allow for an easy DOS on TPROXY sessions?
You should not be processing RST unless you are also processing TCP widows.
Not all RST packets resets "the" session.
Ah, I think I understand now. You only do this when there isn't yet a socket
in the host IP stack. In such case it is needed.
Sounds like it could be made to work for TCP.
UDP is a bit different thou.. but there isn't that big need of a any
connection table there, except for ICMP processing.
Hmm.. regarding ICMP. How do you plan on handle ICMP from the host stack
without TCP window tracking?
Problem: There may be multiple sessions from the same client IP,PORT to the
same PORT on multiple servers, and after NAT there isn't sufficient
information to distinguish these by the addressing alone.
10.0.1.4:52346 -> 192.168.96.32:80
10.0.1.4:52346 -> 192.168.84.253:80
10.0.1.4:52346 -> 188.8.131.52:80
The problem is much more evident if you look at UDP traffic, but exists for
TCP as well. For TCP you can easily see this if there is multiple clients
behind a NAT gateway (for example netfilter SNAT).
Hmm.. this problem probably also applies to the de-NAT:ing of traffic, but
there you can probably get by by querying the socket for the real source
address (original destination address).