tproxy broken in 2.6.32
Hi, I was trying to replace a setup based on a 2.6.27.14 kernel with a 2.6.32-rc8 kernel and found that TPROXY is no longer working. The 2.6.27.14 kernel had the last stable tproxy patch plus some additional fixes (TIME_WAIT, inet_sk_flowi_flags). Since 2.6.32 is supposed to have working tproxy support, i dropped all patches. Now, connections to the local tproxy port no longer arrive at that port.
From the kernel log:
Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:80, lookup type: 2, sock (null) Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:3128, lookup type: 1, sock debae040 Nov 23 12:32:31 scg01-wiwob user.debug kernel: redirecting: proto 6 c0a80208:80 -> 00000000:3128, mark: 880400a0 The redirecting message is the last indication of the packet. tcpdump shows that no answer for the initial packet goes out and the listening socket it not notified either. Andreas
Hi, On Mon, 2009-11-23 at 13:43 +0100, Andreas Schultz wrote:
I was trying to replace a setup based on a 2.6.27.14 kernel with a 2.6.32-rc8 kernel and found that TPROXY is no longer working.
The 2.6.27.14 kernel had the last stable tproxy patch plus some additional fixes (TIME_WAIT, inet_sk_flowi_flags). Since 2.6.32 is supposed to have working tproxy support, i dropped all patches.
Now, connections to the local tproxy port no longer arrive at that port. From the kernel log:
Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:80, lookup type: 2, sock (null) Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:3128, lookup type: 1, sock debae040 Nov 23 12:32:31 scg01-wiwob user.debug kernel: redirecting: proto 6 c0a80208:80 -> 00000000:3128, mark: 880400a0
The redirecting message is the last indication of the packet. tcpdump shows that no answer for the initial packet goes out and the listening socket it not notified either.
I'll have a look at this. In the meantime, could you please post your kernel config, along with a summary of the iptables & ip rules you're using? Cheers, Krisztian
Hi, git bisect shows that TPROXY has been broken by commit f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work with policy routing I had a look at the patch, and it seems logical that this would break TPROXY. Andreas On Wed, Nov 25, 2009 at 9:23 AM, KOVACS Krisztian <hidden@balabit.hu> wrote:
Hi,
On Mon, 2009-11-23 at 13:43 +0100, Andreas Schultz wrote:
I was trying to replace a setup based on a 2.6.27.14 kernel with a 2.6.32-rc8 kernel and found that TPROXY is no longer working.
The 2.6.27.14 kernel had the last stable tproxy patch plus some additional fixes (TIME_WAIT, inet_sk_flowi_flags). Since 2.6.32 is supposed to have working tproxy support, i dropped all patches.
Now, connections to the local tproxy port no longer arrive at that port. From the kernel log:
Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:80, lookup type: 2, sock (null) Nov 23 12:32:31 scg01-wiwob user.debug kernel: tproxy socket lookup: proto 6 ac19c4df:49175 -> c0a80208:3128, lookup type: 1, sock debae040 Nov 23 12:32:31 scg01-wiwob user.debug kernel: redirecting: proto 6 c0a80208:80 -> 00000000:3128, mark: 880400a0
The redirecting message is the last indication of the packet. tcpdump shows that no answer for the initial packet goes out and the listening socket it not notified either.
I'll have a look at this. In the meantime, could you please post your kernel config, along with a summary of the iptables & ip rules you're using?
Cheers, Krisztian
Hi, On Thu, 2009-11-26 at 18:19 +0100, Andreas Schultz wrote:
Hi,
git bisect shows that TPROXY has been broken by commit f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work with policy routing
I had a look at the patch, and it seems logical that this would break TPROXY.
Indeed, that's a good catch. If this is indeed the problem you should be able to work it around by disabling rpfilter on the ingress interface. Does it work that way? Cheers, Krisztian
Hi, On Fri, Nov 27, 2009 at 9:26 AM, KOVACS Krisztian <hidden@balabit.hu> wrote:
Hi,
On Thu, 2009-11-26 at 18:19 +0100, Andreas Schultz wrote:
Hi,
git bisect shows that TPROXY has been broken by commit f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work with policy routing
I had a look at the patch, and it seems logical that this would break TPROXY.
Indeed, that's a good catch. If this is indeed the problem you should be able to work it around by disabling rpfilter on the ingress interface. Does it work that way?
That was my first guess also. I disabled rp_filter on all interfaces and it had no impact. So far, only reverting that patch has solved the problem. Andreas
participants (2)
-
Andreas Schultz
-
KOVACS Krisztian