Removal of ROUTE target - what now?

Removal of ROUTE target - what now?

[John Lumby]

I was a bit surprised to find this gone.      I have read and partially 
understood the recent discussion here about it but I would appreciate some 
help or pointer.

My use of ROUTE is very simple:

Given a P-t-P network interface , call it ppp1, with IPV4 addr a.b.c.d and 
P-t-P address p.q.r.s,
I want any packet with source address a.b.c.d to be routed via gateway 
p.q.r.s regardless of my current routing table.   (the routing table would 
send it through some other gateway).

iptables -t mangle -I POSTROUTING 1 -s a.b.c.d -j ROUTE --gw p.q.r.s

This has worked just fine on kernel 2.6.14 for about 18 months, and use of 
ROUTE target is so simple - just the one rule.

I accept what you say about the ROUTE implementation being "a hack and the 
proper solution to it is policy routing; e.g. based on fwmark."      I 
assume this requires (for my example) having multiple routing tables and so 
on.    I'm also not sure exactly how to do it.      I would really 
appreciate:

   .   if someone could either tell me fairly clearly how to do my 
application with mark and ip route or point to existing example
   .   there is some mention of someone maybe reinstating a fixed version of 
ROUTE - I'd very much like to know if that is happening, in which case I'll 
wait for it.
   ,  or - failing that, is it safe (enough)  to fall back to 
patch-o-matic-ng-20070729 and use its ROUTE?  (in iptables 1.38 and kernel 
2.6.20.9 or later)?

Thanks    John

_________________________________________________________________
Put Your Face In Your Space with Windows Live Spaces 
http://spaces.live.com/?mkt=en-ca

Re: Removal of ROUTE target - what now?

[David Coulson]

ip ru add from a.b.c.d table 20
ip ro add table 20 default via p.q.r.s

you can of course use 'ip ru add fwmark 8 table 20' to use a mark from 
iptables rather than an IP address

Make sure you have reverse path filtering disabled on the interface too.

John Lumby wrote:
> I was a bit surprised to find this gone.      I have read and 
> partially understood the recent discussion here about it but I would 
> appreciate some help or pointer.
>
> My use of ROUTE is very simple:
>
> Given a P-t-P network interface , call it ppp1, with IPV4 addr a.b.c.d 
> and P-t-P address p.q.r.s,
> I want any packet with source address a.b.c.d to be routed via gateway 
> p.q.r.s regardless of my current routing table.   (the routing table 
> would send it through some other gateway).
>
> iptables -t mangle -I POSTROUTING 1 -s a.b.c.d -j ROUTE --gw p.q.r.s
>
> This has worked just fine on kernel 2.6.14 for about 18 months, and 
> use of ROUTE target is so simple - just the one rule.
>
> I accept what you say about the ROUTE implementation being "a hack and 
> the proper solution to it is policy routing; e.g. based on 
> fwmark."      I assume this requires (for my example) having multiple 
> routing tables and so on.    I'm also not sure exactly how to do 
> it.      I would really appreciate:
>
>   .   if someone could either tell me fairly clearly how to do my 
> application with mark and ip route or point to existing example
>   .   there is some mention of someone maybe reinstating a fixed 
> version of ROUTE - I'd very much like to know if that is happening, in 
> which case I'll wait for it.
>   ,  or - failing that, is it safe (enough)  to fall back to 
> patch-o-matic-ng-20070729 and use its ROUTE?  (in iptables 1.38 and 
> kernel 2.6.20.9 or later)?
>
> Thanks    John
>
> _________________________________________________________________
> Put Your Face In Your Space with Windows Live Spaces 
> http://spaces.live.com/?mkt=en-ca
>

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3099 / (216) 258-4942

Re: Removal of ROUTE target - what now?

[Jan Engelhardt]

On Aug 3 2007 21:37, David Coulson wrote:
>
> ip ru add from a.b.c.d table 20
> ip ro add table 20 default via p.q.r.s
>
> you can of course use 'ip ru add fwmark 8 table 20' to use a mark from iptables
> rather than an IP address
>
> Make sure you have reverse path filtering disabled on the interface too.

Since the routing layer now knows about a.b.c.d->p.q.r.s (it does not
when you use ipt_ROUTE), things could work even if RPF are on.
Of course that I what I believe or what I believe should be happening;
if it is not, feel free to correct me :)


	Jan
-- 

Re: Removal of ROUTE target - what now?

[David Coulson]

It has been a while since I was running a configuration like that, 
however I believe that the kernel does not walk every routing table on 
the system in order to establish RPF state.

Might be wrong though - Been a few years.

Jan Engelhardt wrote:
> Since the routing layer now knows about a.b.c.d->p.q.r.s (it does not
> when you use ipt_ROUTE), things could work even if RPF are on.
> Of course that I what I believe or what I believe should be happening;
> if it is not, feel free to correct me :)
>   

Re: Removal of ROUTE target - what now?

[Jan Engelhardt]

On Aug 4 2007 09:47, David Coulson wrote:
>
> It has been a while since I was running a configuration like that, however I
> believe that the kernel does not walk every routing table on the system in
> order to establish RPF state.
>
> Might be wrong though - Been a few years.

According to net/ipv4/fib_frontend.c:fib_validate_source(), it builds a flow
where src/dst and iif/oif are swapped and then does a fib_lookup(), and if
the devices match, everything is wonderful.

However, now that I look at it - the flow's TOS is set, but not its fwmark.
Well, routing code is filled with macros and not instantly 'graspable'.
Maybe one of the maintainers know better.


	Jan
-- 

Re: Removal of ROUTE target - what now?

[John Lumby]

David Coulson wrote:
>
>ip ru add from a.b.c.d table 20
>ip ro add table 20 default via p.q.r.s
>

Thanks - yes, that works (well you knew that but thanks anyway as I didn't).
>
>you can of course use 'ip ru add fwmark 8 table 20' to use a mark from 
>iptables rather than an IP address
>
Didn't try that - seems cleaner to use just the ip routing mechanism.
>
>Make sure you have reverse path filtering disabled on the interface too.
>
Jan Engelhardt wrote:
>
>Since the routing layer now knows about a.b.c.d->p.q.r.s (it does not
>when you use ipt_ROUTE), things could work even if RPF are on.
>Of course that I what I believe or what I believe should be happening;
>if it is not, feel free to correct me
>
>David Coulson wrote:
> >
> > It has been a while since I was running a configuration like that, 
>however I
> > believe that the kernel does not walk every routing table on the system 
>in
> > order to establish RPF state.
> >
> > Might be wrong though - Been a few years.
>
>According to net/ipv4/fib_frontend.c:fib_validate_source(), it builds a 
>flow
>where src/dst and iif/oif are swapped and then does a fib_lookup(), and if
>the devices match, everything is wonderful.
>
>However, now that I look at it - the flow's TOS is set, but not its fwmark.
>Well, routing code is filled with macros and not instantly 'graspable'.
>Maybe one of the maintainers know better.
>
Well, i tested with and without - seems to work in each case.
I had never looked at RPF before but this particular interface comes up with
RPF enabled, and I first disabled it, then established a few conversations  
(SMTP)  which succeeded, then (without dropping the ppp1 IP interface)
echo 1 >/proc/sys/net/ipv4/conf/ppp1/rp_filter
and sent a few more SMTP conversations and they succeeded too.
Don't know if that was a valid test.

Thanks again

John

P.S.   The patch-o-matic extras web page still refers to ipt_ROUTE

_________________________________________________________________
Show Your Messenger Buddies How You Really Feel 
http://www.freemessengeremoticons.ca/?icid=EMENCA122

Re: Removal of ROUTE target - what now?

[Jan Engelhardt]

On Aug 5 2007 21:27, John Lumby wrote:
> Well, i tested with and without - seems to work in each case.
> I had never looked at RPF before but this particular interface comes up with
> RPF enabled, and I first disabled it, then established a few conversations
> (SMTP)  which succeeded, then (without dropping the ppp1 IP interface)
> echo 1 >/proc/sys/net/ipv4/conf/ppp1/rp_filter
> and sent a few more SMTP conversations and they succeeded too.
> Don't know if that was a valid test.

Does it still work when the following three are set to 1?
	/proc/sys/net/ipv4/conf/all/rp_filter
	/proc/sys/net/ipv4/conf/ppp0/rp_filter
	/proc/sys/net/ipv4/conf/ppp1/rp_filter

> P.S.   The patch-o-matic extras web page still refers to ipt_ROUTE

Yeah it lists a lot of other stuff too, that has either been merged
or deleted.


	Jan
-- 

Re: Removal of ROUTE target - what now?

[John Lumby]

Jan Engelhardt  wrote:
>On Aug 5 2007 21:27, John Lumby wrote:
> > Well, i tested with and without - seems to work in each case.
>>  [...]
> > Don't know if that was a valid test.
>
>Does it still work when the following three are set to 1?
>	/proc/sys/net/ipv4/conf/all/rp_filter
>	/proc/sys/net/ipv4/conf/ppp0/rp_filter
>	/proc/sys/net/ipv4/conf/ppp1/rp_filter
>
Yes

The initial settings of the ppp[x]/rp_filter were both 1 and the setting of 
the all/rp_filter was 0.  I set the all rp_filter to 1 AFTER bringing up my 
ppp1 interface (but of course before trying an SMTP session) if that  makes 
any difference.

I'm running kernel 2.6.20.9

John

_________________________________________________________________
Show Your Messenger Buddies How You Really Feel 
http://www.freemessengeremoticons.ca/?icid=EMENCA122