Can't figure out how to make convoluted route...

I'm at a site that has a dedicated line to a remote LAN for a sister office.
We would like to test access to some local resources to make sure that
office can see it, and we'd like to automate it. Ideally, I would like to
pass all packets from MYHOST destined for TESTIP through REMOTEGW.

My first instinct was to simply add a route like:

route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW

.... but you can't do that because $REMOTEGW is about 4 hops away.

So, I though that I could use iptables to do it:

iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW

.... but that didn't work either. For good measure, I made sure to add the
forwarding rule:

iptables -A FORWARD -d $TESTIP -j ACCEPT

.... but I still can't run a traceroute and see packets going via $REMOTEGW
to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is
feasible (after all, there are several switches between $MYHOST and
$REMOTEGW).

Any ideas?

On Fri, 20 Oct 2006 15:15:10 -0400, James McIninch wrote:

> I'm at a site that has a dedicated line to a remote LAN for a sister office.
> We would like to test access to some local resources to make sure that
> office can see it, and we'd like to automate it. Ideally, I would like to
> pass all packets from MYHOST destined for TESTIP through REMOTEGW.
>
> My first instinct was to simply add a route like:
>
> route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW
>
> ... but you can't do that because $REMOTEGW is about 4 hops away.
>
> So, I though that I could use iptables to do it:
>
> iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW
>
> ... but that didn't work either. For good measure, I made sure to add the
> forwarding rule:
>
> iptables -A FORWARD -d $TESTIP -j ACCEPT
>
> ... but I still can't run a traceroute and see packets going via $REMOTEGW
> to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is
> feasible (after all, there are several switches between $MYHOST and
> $REMOTEGW).
>
> Any ideas?

you say 'dedicated line' but then say '4 hops'... not very direct....

Just a shot in the dark, but you probably want to set up a VPN type
tunnel between the local office and the remote office. That way, they
would each have a virtual ethernet port that was directly connected
to the 'other site'.

jack



--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

James McIninch wrote:
> I'm at a site that has a dedicated line to a remote LAN for a sister office.
> We would like to test access to some local resources to make sure that
> office can see it, and we'd like to automate it. Ideally, I would like to
> pass all packets from MYHOST destined for TESTIP through REMOTEGW.
>
> My first instinct was to simply add a route like:
>
> route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW
>
> ... but you can't do that because $REMOTEGW is about 4 hops away.

It would really help if you could provide IP Addresses. Just using
variables forces us to assume too much. Your origination device must
have a route that points to the next-hop router, not one 4 hops away.
Each router along the way must know the nest hop router to both ends.

>
> So, I though that I could use iptables to do it:
>
> iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW
>
> ... but that didn't work either. For good measure, I made sure to add the
> forwarding rule:
>
> iptables -A FORWARD -d $TESTIP -j ACCEPT
>
> ... but I still can't run a traceroute and see packets going via $REMOTEGW
> to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is
> feasible (after all, there are several switches between $MYHOST and
> $REMOTEGW).

The number of switches makes no difference. The link between switches is
not a "hop", if that's what you were referring to earlier in your post.
Going back to what you said about your link being direct between
locations, you just need a setup like this.

192.168.0.2
"Remote Device"
|
|
192.168.0.1
Remote Router
WAN
\
/
\
WAN
Local Router
192.168.1.1
|
|
192.168.1.2
"Local Device"


Local Device IP settings:
IP Address 192.168.1.2
Mask 255.255.255.0
Gateway 192.168.1.1
or
static route to 192.168.0.0/24 via 192.168.1.1

Remote Device IP settings:
IP Address 192.168.0.2
Mask 255.255.255.0
Gateway 192.168.0.1
or
static route to 192.168.1.0/24 via 192.168.0.1

from either end, ping the near router, far router, far device.

.....kurt


>
> Any ideas?

On Fri, 20 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <FvKdncUCM6-(E-Mail Removed)>, James McIninch wrote:

[Just an FYI - while Comcast/giganews does carry 'comp.os.linux.questions'
that group is only found on servers that claim to carry more newsgroups
than anyone else - it was never a real group. That's why it's averaging
less than one article a day.]

>I'm at a site that has a dedicated line to a remote LAN for a sister office.
>We would like to test access to some local resources to make sure that
>office can see it, and we'd like to automate it. Ideally, I would like to
>pass all packets from MYHOST destined for TESTIP through REMOTEGW.

To get to REMOTEGW, it has to go through LOCALGW - and that's all the
kernel cares about.

>My first instinct was to simply add a route like:
>
> route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW

Syntax error - a '-net' doesn't use a 255.255.255.255 mask. That's a
host route, and doesn't want that keyword. Secondly

>... but you can't do that because $REMOTEGW is about 4 hops away.

Amazing! Don't you think it would be more useful to hand the packets
to the local end of the link - and let _that_ system worry about how
stuff gets to the next hop on the way to the remote site?

>So, I though that I could use iptables to do it:

Nope - it's a routing problem

>... but that didn't work either. For good measure, I made sure to add the
>forwarding rule:

Same thing

>... but I still can't run a traceroute and see packets going via $REMOTEGW
>to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is
>feasible (after all, there are several switches between $MYHOST and
>$REMOTEGW).

and it's their job to route packets "onward" through hosts that they are
_DIRECTLY_ connected to.

>Any ideas?

http://tldp.org/guides.html

* The Linux Network Administrator's Guide, Second Edition
version: 1.1
authors: Olaf Kirch and Terry Dawson
last update: March 2000
ISBN: 1-56592-400-2
available formats:
1. HTML (read online)
2. HTML (tarred and gzipped package, 690k)
3. PDF (1.5MB)

Brief concept: Your kernel routes packets to hosts that are DIRECTLY attached
to the LAN. The "router" or modem or what-ever hands the packet to something
that is directly connected to it, and that system forwards the packet to
something else - eventually it gets to the destination, but you don't CARE
about the intermediate steps. That's why internetworking classes always talk
about the Internet being "a cloud" where you stick the packet _in_ here,
and it comes _out_ there. What happens in between is not relevant. All the
kernel needs to know is the final destination, and the address of the box ON
THIS LOCAL NETWORK that will do the forwarding.

Old guy