Mailing List Archive: Removal of ROUTE target - what now?

Removal of ROUTE target - what now?

johnlumby at hotmail

Aug 3, 2007, 6:28 PM

Post #1 of 8 (3240 views)

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? [ In reply to ]

david at davidcoulson

Aug 3, 2007, 6:37 PM

Post #2 of 8 (3163 views)

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? [ In reply to ]

jengelh at computergmbh

Aug 4, 2007, 1:41 AM

Post #3 of 8 (3159 views)

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? [ In reply to ]

david at davidcoulson

Aug 4, 2007, 6:47 AM

Post #4 of 8 (3161 views)

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? [ In reply to ]

jengelh at computergmbh

Aug 4, 2007, 7:22 AM

Post #5 of 8 (3162 views)

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? [ In reply to ]

johnlumby at hotmail

Aug 5, 2007, 6:27 PM

Post #6 of 8 (3150 views)

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? [ In reply to ]

jengelh at computergmbh

Aug 6, 2007, 1:12 AM

Post #7 of 8 (3159 views)

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? [ In reply to ]

johnlumby at hotmail

Aug 6, 2007, 10:50 AM

Post #8 of 8 (3168 views)

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