Mailing List Archive

In article <469F280B.3070900@trash.net> (at Thu, 19 Jul 2007 10:59:55 +0200), Patrick McHardy <kaber@trash.net> says:

> You're right, nf_conntrack_ipv4 only registeres SO_ORIGINAL_DST for
> AF_INET, changing that should make it work I believe. I feel like
> I'm missing something though ..

BTW, the name of the socket option is rather bogus.
It should be named IP_xxx, not SO_xxx because
it is in IP level, not in socket level...

--yoshfuji

From: Patrick McHardy <kaber@trash.net>
Date: Thu, 19 Jul 2007 10:59:55 +0200

> squid3@treenet.co.nz wrote:
> > Greetings,
> >
> > Pardon if this is a dumb question. But I have searched the web, and the
> > source code for a solution to this one and have reached a brick wall.
> >
> > I'm upgrading a user-space proxy (squid3) which has in the past done
> > transparent connections under IPv4-only using SO_ORIGINAL_DST.
> >
> > The Firewall/router uses iptables and REDIRECT port 80 outbound to port
> > 81. All is fine and dandy when squid listens on 0.0.0.0:81.
> >
> > With the new code I have to use an IPv6 socket ( [::]:81 ) as the
> > receiver. With that getsockopt(..., SO_ORIGINAL_DST, ...) always returns
> > err "92 Protocol not supported." regardless of the IP-level parameters
> > passed in.
> >
> > NOTE: All traffic for testing so far has been from IPv4 clients to what
> > they think is an IPv4 server, but with a dual-enabled middleman. The
> > 'middleman' Software is iptables 1.3.6 on Debian 2.6.21-2-486 (unstable),
> > squid3 built with g++ 4.1.3.
>
>
> You're right, nf_conntrack_ipv4 only registeres SO_ORIGINAL_DST for
> AF_INET, changing that should make it work I believe. I feel like
> I'm missing something though ..

I wrote getorigdst() for IPv6 at once but threw away it
because of no IPv6 NAT :) I hope that new tproxy will support IPv6 in future.

-- Yasuyuki Kozakai

YOSHIFUJI Hideaki / $B5HF#1QL@ wrote:
> In article <469F280B.3070900@trash.net> (at Thu, 19 Jul 2007 10:59:55 +0200), Patrick McHardy <kaber@trash.net> says:
>
>
>>You're right, nf_conntrack_ipv4 only registeres SO_ORIGINAL_DST for
>>AF_INET, changing that should make it work I believe. I feel like
>>I'm missing something though ..
>
>
> BTW, the name of the socket option is rather bogus.
> It should be named IP_xxx, not SO_xxx because
> it is in IP level, not in socket level...


True, but its too late to change, we'd need to keep it around at
least for userspace. With TPROXY redirection should work with all
families, so presuming we'll merge it some day this might actually
be useful.

Yasuyuki KOZAKAI wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Thu, 19 Jul 2007 10:59:55 +0200
>
>> squid3@treenet.co.nz wrote:
>>> Greetings,
>>>
>>> Pardon if this is a dumb question. But I have searched the web, and the
>>> source code for a solution to this one and have reached a brick wall.
>>>
>>> I'm upgrading a user-space proxy (squid3) which has in the past done
>>> transparent connections under IPv4-only using SO_ORIGINAL_DST.
>>>
>>> The Firewall/router uses iptables and REDIRECT port 80 outbound to port
>>> 81. All is fine and dandy when squid listens on 0.0.0.0:81.
>>>
>>> With the new code I have to use an IPv6 socket ( [::]:81 ) as the
>>> receiver. With that getsockopt(..., SO_ORIGINAL_DST, ...) always returns
>>> err "92 Protocol not supported." regardless of the IP-level parameters
>>> passed in.
>>>
>>> NOTE: All traffic for testing so far has been from IPv4 clients to what
>>> they think is an IPv4 server, but with a dual-enabled middleman. The
>>> 'middleman' Software is iptables 1.3.6 on Debian 2.6.21-2-486 (unstable),
>>> squid3 built with g++ 4.1.3.
>>
>> You're right, nf_conntrack_ipv4 only registeres SO_ORIGINAL_DST for
>> AF_INET, changing that should make it work I believe. I feel like
>> I'm missing something though ..
>
> I wrote getorigdst() for IPv6 at once but threw away it
> because of no IPv6 NAT :) I hope that new tproxy will support IPv6 in future.
>
> -- Yasuyuki Kozakai


Thanks for everything people.

Well, obviously the REDIRECT is working despite no IPv6 NAT.
What sort of a timeframe should I expect before this case is working?

Amos