RE: "Bug" in howto 4.2.1 Split access and other advice

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Ard:

All your mails seem to come with an attachment I LOVE YOU.VBS 666.dat.
Can you check this out lest you end up spreading virus all over? If I'm
wrong, forgive me.

Mohan

-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]
On Behalf Of Ard van Breemen
Sent: 08 July, 2002 4:52 PM
To: Arthur van Leeuwen
Cc: lartc@mailman.ds9a.nl
Subject: Re:  "Bug" in howto 4.2.1 Split access and other advice


On Fri, Jul 05, 2002 at 08:13:53PM +0200, Arthur van Leeuwen wrote:
> On Fri, 5 Jul 2002, Ard van Breemen wrote:
> > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-link
> > s.html
> > I am not sure who wrote this part or what it was based upon, but
> > since I am working a lot longer now with ip rules, I think I want
> > to add some stuff:
> The stuff that is in the HOWTO was designed and tested back in 1999. 
> Oh, and I am the author. :)
Ok... I would have written the same example, so I was not sure on who's
experience it was based upon. It was not meant as a "the author is
stupid", but more like "do I know the author...". I've told this example
also to many people (before I even heard about the lartc. I usually do
not read HOWTO's or stuff like that), because it was the same setup I
was using at home. But as experience evolves, I now know it is not ok.
> > The example 4.2.1 refers to the picture above, and does a plain ip 
> > rule add from .... table .... The problem with the exampe is that if

> > you connect from the inside (local network) to your if1 ip or if2 
> > ip, that in this example the replies to the local-network are going 
> > out if1 or if2... That is not what you want.
> 
> True. That is indeed a bug. Never saw it in actual practice though: 
> you
> *should*not* connect to the external IP addresses of your router from
> the internal network... for various security reasons and such. But you
are
> right.
Hmmmm, to the linux kernel, an IP address is not really interface bound,
so everybody should be able to connect to any ip address on the router.
My filters are usually only based on interface instead of ip addresses.
Usually rp_filter will do the remaining work. So I see no harm in
connecting to the "external" ip addressess. (Quoted, since they are not
really external or completely bound to an interface, you can always arp
for them on another interface..., eh..., if rp_filter allows that
of-course.)
> 
> [snip]
> 
> Whoa, that was large. I'm not sure I entirely follow you though. The 
> *point* of the extra routing tables is that they take precedence over 
> the default routing tables...
-----------^^^^^^^
That's exactly my point: default routes make the kernel go "hey I found
the route, so I do not have to search anymore", so they should be
*after* the normal routing, but *before* the big catchall default route.
Anything else not being a default route, should of course go before the
normal routing.

I like the way Julian describes it:
"        Or more correctly, to specify the path between
each two subnets, the more specific rules and routes before the others."

So, eventually we will get a good description and a good practices
guide.

-- 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux