* Re: [LARTC] Split Access Detail Question
2003-05-09 3:53 [LARTC] Split Access Detail Question Carol Anne Ogdin
@ 2003-05-09 5:19 ` Martin A. Brown
2003-05-09 13:36 ` Carol Anne Ogdin
2003-05-09 14:29 ` William L. Thomson Jr.
2 siblings, 0 replies; 4+ messages in thread
From: Martin A. Brown @ 2003-05-09 5:19 UTC (permalink / raw)
To: lartc
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@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [LARTC] Split Access Detail Question
2003-05-09 3:53 [LARTC] Split Access Detail Question Carol Anne Ogdin
2003-05-09 5:19 ` Martin A. Brown
2003-05-09 13:36 ` Carol Anne Ogdin
@ 2003-05-09 14:29 ` William L. Thomson Jr.
2 siblings, 0 replies; 4+ messages in thread
From: William L. Thomson Jr. @ 2003-05-09 14:29 UTC (permalink / raw)
To: lartc
On Thu, 2003-05-08 at 23:53, Carol Anne Ogdin wrote:
> 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?
For this I would say under no conditions. If a packet arrives from one
ISP and you respond via another the machine waiting for the packet to
arrive will be confused. It's waiting for a packet from the ISP it sent
the first packet to.
I am not sure you could get away with this under any circumstances.
General rule is what ever interface a packet arrives, reverse packets
should flow over the same interface.
If an app is running with a persistant connection connection to your
network it will want all communication to take place over the same
connection. So if it starts on ISP1, it will remain on ISP1 until the
connection is broken. At which time if an attempt to make another
connection is made, theoretically it will take place via ISP2. Of course
depending on your weights and etc.
It's like asking me a question, and a guy named Bob runs over and tells
you the answer. Of course us humans having intelligence may except the
answer. But if you were waiting on the answer to come from me, getting
one from Bob does not cut the mustard. You will still be waiting for one
from me.
--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios, Inc.
3548 Jamestown Ln.
Jacksonville, FL 32223
Phone/Fax 904.260.2445
http://www.obsidian-studios.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 4+ messages in thread