All of lore.kernel.org
 help / color / mirror / Atom feed
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/

      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.