From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] full policy routing
Date: Thu, 20 Feb 2003 04:43:02 +0000 [thread overview]
Message-ID: <marc-lartc-104571622529849@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104558134019449@msgid-missing>
: hello again martin, i sat down and kind of figured it out, all i have
: to do now is to write some flashy bash script like you did ;)
Tee-hee! Flashy bash script...... I usually write something like this in
the header of my scripts: "crappy little script to do X, Y, and Z". For
some reason (unknown to me and my colleagues), I find this very funny when
I stumble across the script days, weeks, months later....
I already had the super-spiffy four-line loop that clears out the RPDB
before yesterday evening though. That wasn't the off-the-cuff part. (Ah
yes, the truth ALWAYS comes out.)
: this is what i got:
:
: routing tables
: main: all routes
: prohibit: prohibit 0/0
: rules
:
: from defined1 -> 192.168.1/24 lookup main
: from defined2 -> 192.168.1/24 lookup main
: ...
: from definedN -> 192.168.1/24 lookup main
: from 192.168.1/24 -> x lookup main
: from x -> 192.168.1/24 lookup main
: from x -> x lookup prohibit
:
: where x here is an undefined network.
Perhaps I don't completely understand the configuration of your network,
but this should work if (and only if) all connections to the Internet are
initiated from 192.168.1.0/24. If connections to the Internet are
initiated from defined1, defined2, ... definedN, then you'll have to
rethink this solution (sadly).
In your earlier mail today, you indicated that you'd entertain other
approaches to blocking the packets. Why not use iptables or ipchains?
It'd be much easier to block connections from one network to another with
ipchains or iptables. Here's the same basic idea, just with packet
filters:
ALLNETS="192.168.200.0/24 10.10.10.0/24"
ALLNETS="$ALLNETS 172.31.150.0/24"
for SRCNET in $ALLNETS ; do
for DSTNET in $ALLNETS ; do
test $DSTNET = $SRCNET && continue
# -- you could use iptables:
iptables -t filter -I FORWARD -s $SRCNET -d $DSTNET -j DROP
# -- or perhaps you prefer ipchains:
ipchains -I forward -s $SRCNET -d $DSTNET -j DENY
done
done
But, this is more about the policy routing fun, so here's a (slightly)
different approach. Do you have any non-RFC 1918 addresses inside? If
not, a slight modification to the two routing table solution looks like
this:
# -- exceptions to RFC 1918 <--> RFC 1918 denial added below
#
from 192.168.1/24 -> 0/0 lookup main
from 0/0 -> 192.168.1/24 lookup main
#
# -- explicit denial of RFC 1918 <--> RFC 1918 addressing
#
from 10.0.0.0/8 -> 192.168.0.0/16 lookup prohibit
from 172.16.0.0/12 -> 192.168.0.0/16 lookup prohibit
from 192.168.0.0/16 -> 10.0.0.0/8 lookup prohibit
from 172.16.0.0/12 -> 10.0.0.0/8 lookup prohibit
from 192.168.0.0/16 -> 172.16.0.0/12 lookup prohibit
from 10.0.0.0/8 -> 172.16.0.0/12 lookup prohibit
#
# -- lookup into table main for anything beyond here
#
[ explicit rule lookup 32766 into table main ]
In this case, you'd need a smaller set of rules (especially if you don't
have any non RFC-1918 addresses inside).... I'd still add some packet
filtering....(see above).
: the thing is now to really get it straigh with the prio in the rules.
As for rule priority, you don't need to specify an explicit priority.
Just start adding rules with the general case, and work your way up to the
most specific case.
Don't forget to do "ip route flush cache" after you have made a change to
the RPDB. I nearly laughed my head off when I read somebody's remark on
this:
Also, don't forget to do ip route flush cache at the end of your setup
script; otherwise changes will take effect only after some maddeningly
irreproducible delay. [1]
Anyway, how's that for an answer? ;-)
-Martin
[1] http://www.quintillion.com/moat/ipsec%2Brouting/iproute2.html
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-02-20 4:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 15:14 [LARTC] full policy routing Tomas Bonnedahl
2003-02-18 15:26 ` Martin A. Brown
2003-02-18 16:02 ` Tomas Bonnedahl
2003-02-18 16:46 ` Martin A. Brown
2003-02-18 21:01 ` Tomas Bonnedahl
2003-02-19 1:01 ` Martin A. Brown
2003-02-19 16:58 ` Tomas Bonnedahl
2003-02-20 4:43 ` Martin A. Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104571622529849@msgid-missing \
--to=mabrown-lartc@securepipe.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.