Hi,

On szo, nov 28, 2009 at 12:36:14 -0500, jamal wrote:

On Sat, 2009-11-28 at 18:07 +0100, Patrick McHardy wrote:

quoted

Right, its source validation. But the setup is valid, its asking for
specifically marked packets to be delivered locally for transparent
proxying. There's no requirement that rules using marks must resolve
to RTN_UNICAST.

True, but that requirement is needed for source validation;->
i.e it is source address validation imposing the requirement
that we must have a RTN_UNICAST route. The tproxy iproute setup entered
a route that was not RTN_UNICAST. I think that the packet deserves to be
beaten with a club then dropped hard into an abyss (Feel free to come up
with  something more medievial to do to it Patrick;-> )

It doesnt make sense to have a source address that is not unicast
belonging to a host or pretending to belong to a host.

The source address *is* unicast. 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. Your modification has
the assumption that routing is symmetrical, and that reply packets will
have the same mark. That assumption is not necessarily right, and I think
it's not entirely unreasonable to think that not only tproxy setups will
be broken by the change.

So i didnt introduce that logic thats causing this pain.

Well, it depends whether or not you consider the initial setup valid.

If it worked before it was hack or fluke imo ;-> If we think that
source address validation needs to check for something else
additionally, i think thats a separate topic (but doesnt
seem worth a change)

My only concern is that this definitely breaks current setups, and while
we do have a workaround we don't have a way to let all users know what
needs to be done...

-- 
KOVACS Krisztian