Hi,
The reverse path filter tends not to place nicely with IPsec tunnels:
- if the default route is on eth0, say, and the link to the IPsec peer
is on eth1, routes to the tunneled subnets need to be added on eth1 or
the rp_filter will fire when tunneled packets are decrypted. These
routes are not required by the IPsec policy engine; their only purpose
is to satisfy the rp_filter.
- if the route to the peer is sometimes on eth0 and sometimes on eth1
depending on dynamic routing, the rp_filter can't be used at all unless
routes to the tunneled subnets are also shared dynamically. Again, these
routes serve no purpose other than to satisfy the rp_filter.
I believe the rp_filter has a lot of merit for unsecured connections.
For traffic where IPsec policies apply, IPsec supplies a much stronger
verification than rp_filter.
Would it make sense for the rp_filter to be skipped for packets that
pass IPsec verification? I don't know how this would be implemented; I'm
just wondering if there's a good reason not to do it.
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
