I've just run into this the second time. It *is* possible to work around it, but it seems to me rather ugly.
This is what I understand the code to do (somewhat simplified): For a locally generated packet, 1. Look at the "normal" routing table to figure out what interface to use 2. If starting a new connection, and no source address was given by user space, look at the interface to figure out which source address to use 3. Look at the interface to determine what MTU to use 4. Construct an actual packet 5. Shove the new packet through the netfilter, setting fwmark and tos 6. Apply any policy routing, possibly directing the packet out a different interface (7. There's another pass through the netfilter before actually sending the packet, where e.g. masquerading is possible.) The obvious problem is that both source address selection and MTU determination rely on possibly faulty assumptions (i.e. that policy routing won't select a different interface). This can be worked around, for a wrong source address, with masquerading, and in the MTU case, by making sure the first interface has no larger MTU than the final one. However, that is certainly a rather unelegant solution. What *should*, IMHO, be done, is apply the final routing right at the start, determining the final interface, and getting those decisions right the first time. This, unfortunately, isn't particularly easy (or so I believe) with the current netfilter/policy-routing framework. It seems that the packet would need to go through some of the steps twice, the first time as a sort of "intended" packet. Comments? MfG Kai
