[LARTC] Split Access Detail Question

[LARTC] Split Access Detail Question

[Carol Anne Ogdin]

In LARTC (v1.32), under 4.2.1 Split access, the following note appears:

>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 market 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?  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?  Have I overlooked something
important here?

--Carol Anne
                                                                                    
 Carol Anne Ogdin            http://www.net-working.com                530/295-3657 
                                                                                    
 Deep Woods Technology, Inc.  http://www.deepwoods.com        CAOgdin@deepwoods.com 
                                                                                    
  Leveraging technology to                                                          
   restore the soul of the                                                          
        organization                                                                
                                                                                    




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Split Access Detail Question

[Martin A. Brown]

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/

Re: [LARTC] Split Access Detail Question

[Carol Anne Ogdin]

On 05/08 @ 10:19 PM, Martin A. Brown wrote (in part):
   ...<snip>...
>
>Does that answer your question?
>
>-Martin

Elegantly and eloquently!  With help from folks like you in this list, I
may get the hang of this whole thing yet  :-)

--Carol Anne



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Split Access Detail Question

[William L. Thomson Jr.]

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/