Re: RP_FILTER runs too late

[David Ford <david@blue-labs.org>]

Oh I have it working, there is just one workaround requirement and one 
nit with rp_filter.  rp_filter has to be disabled and that is an SNAT 
item.  The workaround for a "pre-routing" snat is to setup ip route 
rules, tag the packets, and finally nat them.  It accomplishes the task 
I need but is in my opinion a hack.

I'd rather see SNAT available in pre-routing and have rp_filter run 
against the packet before it hits the netfilter code.

-d

Rob Landley wrote:

>On Tuesday 07 August 2001 02:43, David Ford wrote:
>
>>I finally figured out why my SNAT setup wasn't working.  I had 1 in
>>eth0/rp_filter and that was silently breaking it.
>>
>>This discussion follows the scripts located at website
>>http://blue-labs.org/ , rc.networking and rc.firewalling.  Both are live
>>meaning you'll see any changes I make.
>>
>>Here's the scoop.  I run a VPN from here to my colo server...but I don't
>>want all my traffic going through the VPN.  So I need to finagle a
>>method of NAT.  Now because the NAT code runs behind the routing code,
>>packets are already heading the wrong direction when they get their
>>headers changed.  Because of that you need to tag them with a mark and
>>implement routing rules based on that mark.  As an aside note, all that
>>could be avoided if SNAT would just be available in PREROUTING.
>>
>>Ok. Now that packets are flowing through the right interfaces, things
>>look good but wait...the reply packets are vanishing without a trace.
>>
>>The culprit is the rp_filter on eth0.  The packet comes in, gets the
>>header rewritten then gets chomped by rp_filter.  I'm not quite sure why
>>because the src is still an external IP and the destination before and
>>after is still an internal IP.
>>
>>Wouldn't the rp_filter be more effective if it came ahead of the nat
>>code?  As it is now, it's useless on that interface.
>>
>>David
>>
>
>I just put up some firewall rules as part of the Dynamic Virtual Private 
>Networking project on sourceforge at http://dvpn.sourceforge.net.  It shows 
>both source and destination nat, port forwarding outside of a box, and a 
>couple other fun goodies.  Not necessarily your kind of VPN, but maybe it'll 
>help...
>
>I'm not sure what you're trying to do, but I got everything I tried to work...
>
>Rob
>