From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] A little problem with Split access?
Date: Mon, 28 Oct 2002 06:00:30 +0000 [thread overview]
Message-ID: <marc-lartc-103578495323040@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103521429613010@msgid-missing>
Sean,
: But the problem is that the hosts in the local network (192.168.0.x)
: can not access the ip addresses of 211.x.x.155(eth2) and
: 218.x.x.20(eth1), even though ip forwarding is turned on. It can only
: ping and access via 192.168.0.1(IP of eth0)
There are a few things you can/should do to try to determine what's
happening to your packets. I think you have been bitten by the multiple
routing tables gotcha! For the record, your iptables and most of
your ip route commands are just fine. Let's take a closer look at your
routing tables, though.
All is well in the main routing table:
: [root@www root]# ip route show
: 211.x.x.128 dev eth2 scope link src 211.x.x.155
: 218.x.x.0 dev eth1 scope link src 218.x.x.20
: 211.x.x.128/25 dev eth2 scope link
: 192.168.0.0/24 dev eth0 scope link
: 218.x.x.0/24 dev eth1 scope link
: 127.0.0.0/8 dev lo scope link
: default via 211.x.x.129 dev eth2
But here, your ancillary routing tables only know of destinations on the
greater Internet. Each of these routing tables needs to know that
192.168.0.0/24 is reachable via eth0. Neither table has been populated
this way.
: [root@www root]# ip route show table SI
: 211.x.x.128 dev eth2 scope link src 211.x.x.155
: default via 211.x.x.129 dev eth2
:
: [root@www root]# ip route show table KT
: 218.x.x.0 dev eth1 scope link src 218.x.x.20
: default via 218.x.x.1 dev eth1
That wouldn't be the end of the world except that you add these rules:
: /sbin/ip rule add from 211.x.x.155 table SI
: /sbin/ip rule add from 218.x.x.20 table KT
So, you can either add routes for 192.168.0.0/24 to tables SI and KT or
you can add another rule to handle all traffic bound for 192.168.0.0/24
here's the ip rule solution, which will need to be the last rule added to
your RPDB:
# ip rule add to 192.168.0.0/24 lookup main
here's a simple script to run when creating ancillary routing tables
- after creating the routing table in main
- before adding the default route to the new table
Here's a bash snippet which will copy the main routing table to table
SI for you:
# ip route show table main | grep -Ev ^default \
> | while read ROUTE ; do
> ip route add table SI $ROUTE
> done
Good luck,
-Martin
--
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/
prev parent reply other threads:[~2002-10-28 6:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-21 15:30 [LARTC] A little problem with Split access? Sean Oh
2002-10-28 6:00 ` 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-103578495323040@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox