On Saturday 26 August 2006 08:17, Herbert Xu wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > Using a fwmark as a key for selecting among multiple routing tables (via > > "ip rule" command) breaks the rp_filter functionality since the fwmark > > field is not initialized in function fib_validate_source. Because of this > > there is no way to assure that outgoing and incoming packets use the same > > routing table. > > Yes this is a problem. However, using the fwmark of the inbound packet > as the key to look up the inverse route isn't the best option since this > doesn't work if the mark generated by a real packet going in the inverse > direction is different.
Dear Herbert, Thank you for your reply. About the problem of incoming packets having a different mark than outgoing packets, can't that be called firewall misconfiguration? I believe that if an admin sets up multiple routing tables than its obviously his responsibility to ensure that packets have a chance of hitting the correct table. After your comment I've experimented with CONNMARK save and restore options and they seemed to work great for the purpose of assuring incoming packets have the same mark as the outgoing ones. Just place a restore at the beginning of the mangle table and a save at the end. You mark your outgoing packets in the middle and the replies are automagically marked! Of course netfilter rules are a matter of site policy, the use of CONNMARK is just my suggestion for avoiding the problem you mentioned at least in the simpler scenarios, where I think the use of rp_filter makes most sense. > This isn't the only problem that rp_filter has of course. For example, > it fails to take IPsec policies into account as well. Unfortunately I don't (yet) know enough about IPsec, but thank you for pointing that out, I'm sure you saved me a lot of effort as I was just about to move to IPsec in the hope it didn't have the same problem. > So perhaps it is time to look at solving this problem in a different way. > One possible approach is to have an rp_filter check in netfilter that > constructs the inverse flow of the packet in question and performs all > relevant lookups, including netfilter and IPsec, before deciding whether > the packet is acceptable or not. That would be great! Do you know if any effort has already started towards this end? Actually, I must tell that I'm quite skeptical about its feasibility in the near future as I can't figure out how it's possible to automatically deduce what the fate of a "reversed" packet would have been if it had passed through a _statefull_ firewall. It seems to me that it would require a reversal of the state machine and I'm not sure that it's inverse would be causal, but I'm definitely no expert on this matter, and this idea surely deserves more thinking time than I can afford right now :-) ! > This would have the added benefit that > it can be turned on/off based on criteria other than the interface via > which a packet arrived on. Sorry, but I don't see why the same can't be done with the current implementation/proposed fix. Only a manual reversal of the rules, instead of an automatic reversal, would be necessary, or did I miss something? Best regards, giorby. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
