Q: Is patching the iptables userspace necessary if I just want to fool around with the example programs, say foreign-tcp-connect? Thanks, N
Q: Is patching the iptables userspace necessary if I just want to fool around with the example programs, say foreign-tcp-connect?
No, only if you want to modify the kernel ip tables. (Which is not required if you only want to fake addresses.) Jan Engelhardt --
Thanks for the response. Here's my problem: I'm running foreign-tcp-connect on a machine (say 1.2.3.4) to fake a source address (say 5.6.7.8 port 9999) when connecting to a web server. I get a connect timeout. At the webserver, when I do a tcpdump, it seems that only the port is being faked, not the IP address. That is, the tcpdump output shows that I'm trying to connect from 1.2.3.4 port 9999. If I use 5.6.7.8 as the fake IP address, it works. Has anyone experienced this problem? What am I missing? My setup: Linux kernel 2.6.15.3 (pristine) patched with tproxy-2.6.15-2.0.4 Many thanks, N On 4/6/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
Q: Is patching the iptables userspace necessary if I just want to fool around with the example programs, say foreign-tcp-connect?
No, only if you want to modify the kernel ip tables. (Which is not required if you only want to fake addresses.)
Jan Engelhardt --
Hi there, It turns out that the port isn't being faked either. I'm only able to connect if I set the foreign IP address equal to the local IP address and the foreign port equal to the local port. A tcpdump at the client shows that the IP headers aren't being modified. It's as if tproxy is creating entries in the hash table (TPROXY_ASSIGN and the subsequent call to setsockopt() is successful), but isn't overwriting the approriate fields in the IP headers. Any thoughts? N On 4/6/06, Nguyen Nguyen <n3nguyen@gmail.com > wrote:
Thanks for the response.
Here's my problem: I'm running foreign-tcp-connect on a machine (say 1.2.3.4) to fake a source address (say 5.6.7.8 port 9999) when connecting to a web server. I get a connect timeout.
At the webserver, when I do a tcpdump, it seems that only the port is being faked, not the IP address. That is, the tcpdump output shows that I'm trying to connect from 1.2.3.4 port 9999.
If I use 5.6.7.8 as the fake IP address, it works. Has anyone experienced this problem? What am I missing?
My setup: Linux kernel 2.6.15.3 (pristine) patched with tproxy-2.6.15-2.0.4
Many thanks, N
On 4/6/06, Jan Engelhardt <jengelh@linux01.gwdg.de > wrote:
Q: Is patching the iptables userspace necessary if I just want to fool around with the example programs, say foreign-tcp-connect?
No, only if you want to modify the kernel ip tables. (Which is not required if you only want to fake addresses.)
Jan Engelhardt --
It turns out that the port isn't being faked either.
I'm only able to connect if I set the foreign IP address equal to the local IP address and the foreign port equal to the local port.
A tcpdump at the client shows that the IP headers aren't being modified. It's as if tproxy is creating entries in the hash table (TPROXY_ASSIGN and the subsequent call to setsockopt() is successful), but isn't overwriting the approriate fields in the IP headers.
Any thoughts?
Nguyen, If you bind() explicitly to 1.2.3.4, does it work then? Just a guess... Krisztian, any thoughts? Seems to be the reason why I need 'tcp_outgoing_address' in Squid... Jan Engelhardt --
Hi, On Friday 07 April 2006 10.40, Jan Engelhardt wrote:
It turns out that the port isn't being faked either.
I'm only able to connect if I set the foreign IP address equal to the local IP address and the foreign port equal to the local port.
A tcpdump at the client shows that the IP headers aren't being modified. It's as if tproxy is creating entries in the hash table (TPROXY_ASSIGN and the subsequent call to setsockopt() is successful), but isn't overwriting the approriate fields in the IP headers.
Any thoughts?
Nguyen, If you bind() explicitly to 1.2.3.4, does it work then? Just a guess...
Krisztian, any thoughts? Seems to be the reason why I need 'tcp_outgoing_address' in Squid...
Take a look at your kernel log, maybe you can find some tproxy-related messages there (lines containing IP_TPROXY). In case you can't find anything in the logs I'd suggest enabling debug output. (Replace '#if 0' with '#if 1' before the '#define DEBUGP printk' line in net/ipv4/netfilter/iptable_tproxy.c) This will spit out a lot of debug messages which may be helpful in diagnosing the problem. -- Regards, Krisztian Kovacs
I've figured out my problem: I need to load the iptable_nat module. Thanks for your help. Jan, regarding the tcp_outgoing_address in Squid: I'm guessing you need it because Squid, by default, binds sockets to 0.0.0.0. This means that when you try to do a TPROXY_ASSIGN, it will fail (specifically, setsockopt() will with errno = EINVAL). Maybe you're referring to something else entirely, in which case you should just disregard my comment. N On 4/7/06, KOVACS Krisztian <hidden@balabit.hu> wrote:
Hi,
On Friday 07 April 2006 10.40, Jan Engelhardt wrote:
It turns out that the port isn't being faked either.
I'm only able to connect if I set the foreign IP address equal to the local IP address and the foreign port equal to the local port.
A tcpdump at the client shows that the IP headers aren't being modified. It's as if tproxy is creating entries in the hash table (TPROXY_ASSIGN and the subsequent call to setsockopt() is successful), but isn't overwriting the approriate fields in the IP headers.
Any thoughts?
Nguyen, If you bind() explicitly to 1.2.3.4, does it work then? Just a guess...
Krisztian, any thoughts? Seems to be the reason why I need 'tcp_outgoing_address' in Squid...
Take a look at your kernel log, maybe you can find some tproxy-related messages there (lines containing IP_TPROXY).
In case you can't find anything in the logs I'd suggest enabling debug output. (Replace '#if 0' with '#if 1' before the '#define DEBUGP printk' line in net/ipv4/netfilter/iptable_tproxy.c) This will spit out a lot of debug messages which may be helpful in diagnosing the problem.
-- Regards, Krisztian Kovacs
the tcp_outgoing_address in Squid: I'm guessing you need it because Squid, by default, binds sockets to 0.0.0.0. This means that when you try to do a TPROXY_ASSIGN, it will fail (specifically, setsockopt() will with errno = EINVAL). Maybe you're
bind()ing is - or at least should be - completely independent of TPROXY_ASSIGN.
referring to something else entirely, in which case you should just disregard my comment.
Jan Engelhardt --
participants (3)
-
Jan Engelhardt
-
KOVACS Krisztian
-
Nguyen Nguyen