Re: RP_FILTER runs too late

Re: RP_FILTER runs too late

[Rob Landley]

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

RP_FILTER runs too late

[David Ford]

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

Re: RP_FILTER runs too late

[David Ford]

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
>

Re: RP_FILTER runs too late

[Dan Hollis]

On Tue, 7 Aug 2001, David Ford wrote:
> I'd rather see SNAT available in pre-routing and have rp_filter run
> against the packet before it hits the netfilter code.

There is one other problem with rp_filter.... rp_filter violations are
S I L E N T. You never know when traffic is dropped because of it. Packets
just disappear.

If it generated printk's it would make it a lot easier to track down
filtering problems.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: RP_FILTER runs too late

[Rob Landley]

On Tuesday 07 August 2001 15:07, Dan Hollis wrote:
> On Tue, 7 Aug 2001, David Ford wrote:
> > I'd rather see SNAT available in pre-routing and have rp_filter run
> > against the packet before it hits the netfilter code.

I believe the reason they put SNAT at the end is that when we're about to 
send out we no longer care what the source address is, but before that we do, 
and changing it early would overwrite fields the rest of the network stack is 
still using.  (Same reason dnat happens first thing.  If we redirect it, we 
want it the rest of the network stack to use the NEW destination, and among 
other things send it out the right interface...)

Principle of "least amount of new code".  (Laziness IS one of Larry Wall's 
Seven Deadly Virtues in programmers...)

> There is one other problem with rp_filter.... rp_filter violations are
> S I L E N T. You never know when traffic is dropped because of it. Packets
> just disappear.
>
> If it generated printk's it would make it a lot easier to track down
> filtering problems.

There is a logging option, but it needs a lot of extra knobs if you ask me.  
(Logging to a file would be nice.  I suspect there's a way to do that but I 
couldn't find it circa 2.4.3, which is the last time I gave it much thought.  
Also "log if last rule triggered".  Haven't been bothered enough to break 
open the source other than for debugging purposes, though...)

> -Dan

Rob