Re: [tproxy,regression] tproxy broken in 2.6.32

[KOVACS Krisztian <hidden@sch.bme.hu>]

Hi,

On szo, nov 28, 2009 at 02:44:02 -0500, jamal wrote:
> > The source address *is* unicast. 
> 
> Sorry - I meant the route type is unicast. The fact that an address is
> unicast or not is already dealt with by the time you get to source
> address validation (in ip_input())
> 
> > The problem is that the routing setup is
> > asymmetrical, as Patrick has already mentioned: we're using a mark to
> > force certain packets (those that have matching sockets on the host) being
> > delivered locally.
> >
> > In the other direction, reply packets won't be marked by the iptables
> > rules and thus will be routed on egress just fine. 
> 
> In that case i dont understand the reluctance to use unicast routes.
> Maybe you can explain and put me at ease because i see youve put extra
> effort to use local addresses. 

The short answer is: it doesn't work with unicast routes.

The story is that we really do want to deliver these packets locally, as
if the destination IP address was locally configured on the host. The only
way I know of to get the packet to ip_local_deliver() is by using a local
route.

(Now that you mentioned this I've actually gave it a try. Changing 'local'
in the route to 'unicast' doesn't work at all: incoming packets get
dropped because forwarding is not enabled on the ingress interface.)

-- 
KOVACS Krisztian