: 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@xxxxxxxxxxxxxx
