Hello Carol Anne,
: >Reader Rod Roark notes: 'If $P0_NET is the local network and $IF0 is
: >its interface, the following additional entries are desirable:
: >
: > ip route add $P0_NET dev $IF0 table T1
: > ip route add $P2_NET dev $IF2 table T1 ***
: > ip route add 127.0.0.0/8 dev lo table T1
: > ip route add $P0_NET dev $IF0 table T2
: > ip route add $P1_NET dev $IF1 table T2 ***
: > ip route add 127.0.0.0/8 dev lo table T2
: I've marked two particular lines for my question: Wouldn't these two
: lines (marked with ***) explicitly permit traffic arriving on $IF1
: ($P1_NET) to be routed back out on $IF2 ($P2_NET), and vice versa?
Strangely, the answer is yes, but not because of the two lines you marked
above. So, the unambiguous answer to your question is no, the two lines
above do not explicitly permit this behaviour. Let's examine why these
rules aren't the problem, and find out what is!
: Have I overlooked something important here?
Yes, in fact, the RPDB! Just above the content you snipped from the LARTC
document, there are a few "ip rule" lines and a few routes. These are
good background for this discussion. Do not forget also, that there is a
main routing table with a default route via $P1 in addition to all of the
local routes.
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
ip route add default via $P1 table T1
ip route add default via $P2 table T2
This is a common and simple split access solution. Let's look at the two
most likely scenarios for inbound traffic.
Scenario one (0/0 --> $IP1, inbound $IF1):
- Packet arrives on $IF1 from the Internet bound for a service on $IP1.
- When an outbound packet is generated, the source address on the
packet will be $IP1.
- During the RPDB lookup, as part of the route lookup process, table
T1 will be chosen.
- Now, for any of the locally reachable destinations 127.0.0.1/8,
$P0_NET, $P1_NET, or $P2_NET, the packet can be directly delivered.
- If the packet destination is elsewhere, the default route "via $P1"
will be chosen.
Scenario two (0/0 --> $IP2, inbound $IF2):
- Is exactly the same as above, but with $IP2, $IF2, $P2.
Scenario three ($EVIL_HACKER* --> $P2_NET, inbound on $IF1):
- Now, what happens when the packet is inbound on $IF1 from $EVIL_HACKER
(on Internet, 0/0) bound for $P2_NET (but not $IP2).
- The RPDB lookup will fall through to the main routing table, which
has an entry for $P2_NET.
- The packet will get through! (see more below)
Scenario four ($DESKTOP --> $WEBSITE, inbound on $IF0):
Switching modes to discursive mode.... This is the most complex
scenario, because there are many different ways to configure an
iptables or an ipchains box for masquerading. The source address on
the packet after masquerading/SNAT is used in the route lookup. That's
why the two "ip rule" statements exist. This allows an admin to select
the public source IP based on any packet characteristics available in
the packet filtering engine of choice.
: Under what conditions would I want traffic arriving at my router from
: ISP #1 to be sent back out to ISP #2, or vice versa?
Care to play a circular logic game? You would want traffic arriving at
your router from ISP #1 to be sent back out to ISP #2 if you wanted
traffic arriving from ISP #1 to be sent back out to ISP #2. :)
Seriously, though, it's probably not a configuration most people would
choose, and one I would suggest is probably best addressed with a sensible
packet filter. Naturally it doesn't hurt to configure the routing tables
to prevent this possiblity, but I'd use a packet filter to ensure I was
solving the problem. A little ingress filtering with ipchains or iptables
will solve the problem quite handily.
Does that answer your question?
-Martin
* $EVIL_HACKER's address is naturally inside 0/0, somewhere across
your link to ISP1. Note also, that in scenario three the result is
a touch different with different set of answers if the packet from
$EVIL_HACKER is addressed to $P2, but, hey, one problem at a time!
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
