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:

...

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