Re: [tproxy] netcat for tproxy (and additional noob questions)
Hi, On Tue, Jul 07, 2009 at 07:49:17AM -0400, John Lauro wrote:
I have a very simplistic patch for netcat here:
http://home.sch.bme.hu/~piglet/netfilter/tproxy/netcat-ip_transparent- support.patch
I think I came across that patch before. The problem is I can not find that version (1.10) of netcat anywhere. Found some places that mention being pointers to it, but dead links... It appears there a new GNU version that has lower version number, and also a BSD version, but it is way different too (or at least different enough that the patch doesn't apply).
I think it was based on Debian netcat, so you could give the Debian version a try: ftp://ftp.debian.org/debian/pool/main/n/netcat/
Reusing the original port is usually a bad idea. A notable example of things breaking is Netfilter connection tracking, which gets confused if you reuse the exact same endpoints for a different connection.
Technically they are not the exact same if you include the interface. If it doesn't consider the interface then they would appear the same.
Netfilter conntrack is interface agnostic -- and you're right that it's exactly that what's causing the problem here. -- KOVACS Krisztian
2009/7/7 KOVACS Krisztian <hidden@sch.bme.hu>:
Reusing the original port is usually a bad idea. A notable example of things breaking is Netfilter connection tracking, which gets confused if you reuse the exact same endpoints for a different connection.
Technically they are not the exact same if you include the interface. If it doesn't consider the interface then they would appear the same.
Netfilter conntrack is interface agnostic -- and you're right that it's exactly that what's causing the problem here.
So are you saying that the Linux TPROXY4 code as it stands won't handle the case of a client sending a connection out with a source port that the TPROXY4 proxy is currently using itself for a client IP spoofed connection? Adrian
Hi, On sze, júl 08, 2009 at 02:19:41 +0800, Adrian Chadd wrote:
2009/7/7 KOVACS Krisztian <hidden@sch.bme.hu>:
Reusing the original port is usually a bad idea. A notable example of things breaking is Netfilter connection tracking, which gets confused if you reuse the exact same endpoints for a different connection.
Technically they are not the exact same if you include the interface. If it doesn't consider the interface then they would appear the same.
Netfilter conntrack is interface agnostic -- and you're right that it's exactly that what's causing the problem here.
So are you saying that the Linux TPROXY4 code as it stands won't handle the case of a client sending a connection out with a source port that the TPROXY4 proxy is currently using itself for a client IP spoofed connection?
No, it's just that if you happen to have Netfilter conntrack loaded it won't work. This is a limitation of connection tracking. Transparent proxy support in the kernel doesn't require connection tracking, so if you're not using that the scenario above should work just fine. -- KOVACS Krisztian
participants (2)
-
Adrian Chadd
-
KOVACS Krisztian