when you are using full policy routing (multiple tables and rules for every
network),
is one supposed to wipe all the tables clean with

"ip route flush table all"

or use

"ip route flush table main"

and still be sure that the policy routing works as it's supposed to?

indeed, i dont know what the local and default tables are really doing.


enlighentment would be appriciated.

best regards,
tomas

Tomas,

It never occurred to me to try "ip route flush table all".  Does it
work?
[ I'll have to try that on my critical Internet connected router! ;-) ]

I have gotten in the habit of using "ip route flush table $ID" for any
table I'm about to populate with routes.  This way, I know I'm starting
from an empty routing table.  Typically I don't muck about with the main
routing table, and just use the RPDB to override the routes configured in
the main routing table.

I don't know what you mean by the "default" routing table, but the
local
routing table is a very important routing table--it's the first one
consulted in most route lookups, to see if the IP is a locally hosted IP,
a broadcast address, or a (dumb) NAT transformation.

Have a good day,

-Martin

: when you are using full policy routing (multiple tables and rules for every
network),
 : is one supposed to wipe all the tables clean with
 :
 : "ip route flush table all"
 :
 : or use
 :
 : "ip route flush table main"
 :
 : and still be sure that the policy routing works as it's supposed to?
 :
 : indeed, i dont know what the local and default tables are really doing.
 :
 :
 : enlighentment would be appriciated.
 :
 : best regards,
 : tomas
 : _______________________________________________
 : LARTC mailing list / LARTC@mailman.ds9a.nl
 : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
 :

--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

hello martin, thank you for your quick reply.

(the default routing table is empty for me, but is listed in
/etc/iproute2/rt_tables)

i want to use "as much" rules as i can, meaning that the main table
will only have one route to my network that come from networks
not defined in the rules.

now, about the local table. if the local table is the first one consulted when
the router is to determine a path for a packet, i dont
want that to be filled with rules that is not defined from that network, but the
rules maybe override that? when i looked in my local
table, i just see broadcast address and local connected addresses, as you also
said.

any idea? it seems best to go with "ip route flush table main", btw,
you also reminded me to clean the other tables too when
re-populating the tables, i forgot it. thank you. ;)

you probably understand that my native language is not english. please feel free
to ask if there's something in this you dont
understand.


best regards,
tomas

On Tue, Feb 18, 2003 at 09:26:06AM -0600, Martin A. Brown wrote:
>
> Tomas,
>
> It never occurred to me to try "ip route flush table all".  Does
it work?
> [ I'll have to try that on my critical Internet connected router! ;-) ]
>
> I have gotten in the habit of using "ip route flush table $ID"
for any
> table I'm about to populate with routes.  This way, I know I'm starting
> from an empty routing table.  Typically I don't muck about with the main
> routing table, and just use the RPDB to override the routes configured in
> the main routing table.
>
> I don't know what you mean by the "default" routing table, but
the local
> routing table is a very important routing table--it's the first one
> consulted in most route lookups, to see if the IP is a locally hosted IP,
> a broadcast address, or a (dumb) NAT transformation.
>
> Have a good day,
>
> -Martin
>
>  : when you are using full policy routing (multiple tables and rules for
every network),
>  : is one supposed to wipe all the tables clean with
>  :
>  : "ip route flush table all"
>  :
>  : or use
>  :
>  : "ip route flush table main"
>  :
>  : and still be sure that the policy routing works as it's supposed to?
>  :
>  : indeed, i dont know what the local and default tables are really doing.
>  :
>  :
>  : enlighentment would be appriciated.
>  :
>  : best regards,
>  : tomas
>  : _______________________________________________
>  : LARTC mailing list / LARTC@mailman.ds9a.nl
>  : http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>  :
>
> --
> Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
>
>

: hello martin, thank you for your quick reply.

My pleasure.

 : (the default routing table is empty for me, but is listed in
 : /etc/iproute2/rt_tables)

True indeed....I guess I just don't know if it's a special table or just a
convention.  I have never used it.  Any others on the list use the default
table (table 253)?

 : i want to use "as much" rules as i can, meaning that the main table
 : will only have one route to my network that come from networks not
 : defined in the rules.

I'm not quite sure I understand this completely.  Do you wish to prefer
the RPDB for route selection?  I don't see any technical reason you
couldn't configure one routing table for each class of outbound route, but
it seems somewhat counterintuitive.  Then again, perhaps I do not
understand your desired goal.  Explain more--sounds like an interesting
approach.

 : now, about the local table. if the local table is the first one
 : consulted when the router is to determine a path for a packet, i dont
 : want that to be filled with rules that is not defined from that
 : network, but the rules maybe override that? when i looked in my local
 : table, i just see broadcast address and local connected addresses, as
 : you also said.

The local table has only broadcast, local, and nat routes.  There will not
be routes for remote networks--try it, and you'll get:

RTNETLINK answers: Invalid argument

: any idea? it seems best to go with "ip route flush table main",
btw,
 : you also reminded me to clean the other tables too when re-populating
 : the tables, i forgot it. thank you. ;)

I have been bitten by that one before, too!  ;)

-Martin

--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

hello again martin.

the setup i have in mind is not very exciting really. ;(

what i have is an internal router that transports data from ten different
defined networks and of course "internet traffic". one of these
defined
networks is our lan 192.168.1/24.

the utopia that im trying to reach is that there is a routing table for each and
every one of these defined networks. these routing tables will pretty
much only say "192.168.1/24 is on eth1. drop all other traffic that is not
destined for 192.168.1/24".
of course the table for 192.168.1/24 will have routes for all of these networks
plus a default route to the internet. i then use rules for directing
"from network x, use table x". the main table will just have one
route, to 192.168.1/24 so that "internet traffic" can get through.

this is just for security, that a ipsec defined network cannot reach the voIP
network and so on, every network should just be able to reach the lan.


should this work? perhaps that was what you meant when you talked about RPDB?

btw, seems like trouble shooting with policy routing isnt the easiest ;x



thanks,
tomas


On Tue, Feb 18, 2003 at 10:46:52AM -0600, Martin A. Brown wrote:
>  : hello martin, thank you for your quick reply.
>
> My pleasure.
>
>  : (the default routing table is empty for me, but is listed in
>  : /etc/iproute2/rt_tables)
>
> True indeed....I guess I just don't know if it's a special table or just a
> convention.  I have never used it.  Any others on the list use the default
> table (table 253)?
>
>  : i want to use "as much" rules as i can, meaning that the main
table
>  : will only have one route to my network that come from networks not
>  : defined in the rules.
>
> I'm not quite sure I understand this completely.  Do you wish to prefer
> the RPDB for route selection?  I don't see any technical reason you
> couldn't configure one routing table for each class of outbound route, but
> it seems somewhat counterintuitive.  Then again, perhaps I do not
> understand your desired goal.  Explain more--sounds like an interesting
> approach.
>
>  : now, about the local table. if the local table is the first one
>  : consulted when the router is to determine a path for a packet, i dont
>  : want that to be filled with rules that is not defined from that
>  : network, but the rules maybe override that? when i looked in my local
>  : table, i just see broadcast address and local connected addresses, as
>  : you also said.
>
> The local table has only broadcast, local, and nat routes.  There will not
> be routes for remote networks--try it, and you'll get:
>
> RTNETLINK answers: Invalid argument
>
>  : any idea? it seems best to go with "ip route flush table
main", btw,
>  : you also reminded me to clean the other tables too when re-populating
>  : the tables, i forgot it. thank you. ;)
>
> I have been bitten by that one before, too!  ;)
>
> -Martin
>
> --
> Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
>
>

: what i have is an internal router that transports data from ten
 : different defined networks and of course "internet traffic". one of
 : these defined networks is our lan 192.168.1/24.
 :
 : the utopia that im trying to reach is that there is a routing table for
 : each and every one of these defined networks. these routing tables will
 : pretty much only say "192.168.1/24 is on eth1. drop all other traffic
 : that is not destined for 192.168.1/24". of course the table for
 : 192.168.1/24 will have routes for all of these networks plus a default
 : route to the internet. i then use rules for directing "from network x,
 : use table x". the main table will just have one route, to 192.168.1/24
 : so that "internet traffic" can get through.

I guess I can see why you'd want this, although I wouldn't recommend
relying on routing to enforce your security.  It can't hurt as an
additional measure, though.

I think you could make good use of the prohibit route.  In the example
script I just cooked up (see below), I have used a table whose sole
purpose is to return a prohibit route.  This way, you can use the RPDB to
perform a lookup for any route to any other network.  I'm not great at
algorithms, so I'm sure somebody else out there will have a better
suggestion for how to cheaply achieve the same end.  That said, you should
be able to define your networks in the $CONFIG file and have a bunch of
rules entered saying--you can't go here from there.

I think the big benefit here is that you are specifically "DENY"ing
traffic based on source and destination pairings.  This means you only
have to manage two routing tables, not number-of-networks tables.  The
main routing table is still used by all hosts, unless the RPDB suggests
looking up in table prohibit-table.

 : this is just for security, that a ipsec defined network cannot reach
 : the voIP network and so on, every network should just be able to reach
 : the lan.
 :
 : should this work? perhaps that was what you meant when you talked about
 : RPDB?

Yes.  Most definitely.

 : btw, seems like trouble shooting with policy routing isnt the easiest
 : ;x

Indeed.  It takes a bit of patience, tcpdump, printing out all of the
routing tables and the RPDB, and some patience.  But by remembering that
it's just a big stateless mechanism, you ease your burden.

Did I mention that it requires patience?

-Martin

# cat destinations
172.16.0.0/24          ipsec
172.17.108.0/24        voip
192.168.132.0/24       modempool
10.251.8.0/24          serverfarm
172.195.44.0/24        turnip
192.168.12.0/24        internal
10.49.85.0/24          ldapnet



#! /bin/bash
#
# -- populate some tables

CONFIG=destinations

ALLNETS=$( awk '{print $1 }' $CONFIG )

ip rule show | grep -Ev '^(0|32766|32767):|iif lo' \
  | while read PRIO RULE; do
  ip rule del prio ${PRIO%%:*} $( echo $RULE | sed 's|all|0/0|' )
done

TABLES=/etc/iproute2/rt_tables

grep -q prohibit-table $TABLES || echo  249 prohibit-table >> $TABLES
ip route add prohibit default table prohibit-table

while read NETADDR NETNAME GARBAGE ; do
  #
  # -- cycle through all of the networks, adding prohibit routes
  #ot@piggles bonnedahl]#  ./maketables.sh
  for DEST in $ALLNETS ; do

    test $DEST = $NETADDR && continue
    ip rule add from $NETADDR to $DEST lookup prohibit-table

  done

done < $CONFIG

--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

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 ;)

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.

the thing is now to really get it straigh with the prio in the rules.

if you are able to, i would like a comment on it.

thanks,
tomas


On Tue, Feb 18, 2003 at 07:01:52PM -0600, Martin A. Brown wrote:
>  : what i have is an internal router that transports data from ten
>  : different defined networks and of course "internet traffic".
one of
>  : these defined networks is our lan 192.168.1/24.
>  :
>  : the utopia that im trying to reach is that there is a routing table for
>  : each and every one of these defined networks. these routing tables will
>  : pretty much only say "192.168.1/24 is on eth1. drop all other
traffic
>  : that is not destined for 192.168.1/24". of course the table for
>  : 192.168.1/24 will have routes for all of these networks plus a default
>  : route to the internet. i then use rules for directing "from network
x,
>  : use table x". the main table will just have one route, to
192.168.1/24
>  : so that "internet traffic" can get through.
>
> I guess I can see why you'd want this, although I wouldn't recommend
> relying on routing to enforce your security.  It can't hurt as an
> additional measure, though.
>
> I think you could make good use of the prohibit route.  In the example
> script I just cooked up (see below), I have used a table whose sole
> purpose is to return a prohibit route.  This way, you can use the RPDB to
> perform a lookup for any route to any other network.  I'm not great at
> algorithms, so I'm sure somebody else out there will have a better
> suggestion for how to cheaply achieve the same end.  That said, you should
> be able to define your networks in the $CONFIG file and have a bunch of
> rules entered saying--you can't go here from there.
>
> I think the big benefit here is that you are specifically
"DENY"ing
> traffic based on source and destination pairings.  This means you only
> have to manage two routing tables, not number-of-networks tables.  The
> main routing table is still used by all hosts, unless the RPDB suggests
> looking up in table prohibit-table.
>
>  : this is just for security, that a ipsec defined network cannot reach
>  : the voIP network and so on, every network should just be able to reach
>  : the lan.
>  :
>  : should this work? perhaps that was what you meant when you talked about
>  : RPDB?
>
> Yes.  Most definitely.
>
>  : btw, seems like trouble shooting with policy routing isnt the easiest
>  : ;x
>
> Indeed.  It takes a bit of patience, tcpdump, printing out all of the
> routing tables and the RPDB, and some patience.  But by remembering that
> it's just a big stateless mechanism, you ease your burden.
>
> Did I mention that it requires patience?
>
> -Martin
>
> # cat destinations
> 172.16.0.0/24          ipsec
> 172.17.108.0/24        voip
> 192.168.132.0/24       modempool
> 10.251.8.0/24          serverfarm
> 172.195.44.0/24        turnip
> 192.168.12.0/24        internal
> 10.49.85.0/24          ldapnet
>
>
>
> #! /bin/bash
> #
> # -- populate some tables
>
> CONFIG=destinations
>
> ALLNETS=$( awk '{print $1 }' $CONFIG )
>
> ip rule show | grep -Ev '^(0|32766|32767):|iif lo' \
>   | while read PRIO RULE; do
>   ip rule del prio ${PRIO%%:*} $( echo $RULE | sed 's|all|0/0|' )
> done
>
> TABLES=/etc/iproute2/rt_tables
>
> grep -q prohibit-table $TABLES || echo  249 prohibit-table >> $TABLES
> ip route add prohibit default table prohibit-table
>
> while read NETADDR NETNAME GARBAGE ; do
>   #
>   # -- cycle through all of the networks, adding prohibit routes
>   #ot@piggles bonnedahl]#  ./maketables.sh
>   for DEST in $ALLNETS ; do
>
>     test $DEST = $NETADDR && continue
>     ip rule add from $NETADDR to $DEST lookup prohibit-table
>
>   done
>
> done < $CONFIG
>
> --
> Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
>
>

: 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