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

Discussion in 'Linux Networking' started by James McIninch, Oct 20, 2006.

  1. 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 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

    Any ideas?
    James McIninch, Oct 20, 2006
    1. Advertisements

  2. 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'.


    D.A.M. - Mothers Against Dyslexia

    see for my contact info.

    jack - Grapevine/Richardson
    Jack Snodgrass, Oct 21, 2006
    1. Advertisements

  3. James McIninch

    kurt Guest

    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.
    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.
    "Remote Device"
    Remote Router
    Local Router
    "Local Device"

    Local Device IP settings:
    IP Address
    static route to via

    Remote Device IP settings:
    IP Address
    static route to via

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

    kurt, Oct 21, 2006
  4. James McIninch

    Moe Trin Guest

    On Fri, 20 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in

    [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.]
    To get to REMOTEGW, it has to go through LOCALGW - and that's all the
    kernel cares about.
    Syntax error - a '-net' doesn't use a mask. That's a
    host route, and doesn't want that keyword. Secondly
    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?
    Nope - it's a routing problem
    Same thing
    and it's their job to route packets "onward" through hosts that they are
    _DIRECTLY_ connected to.

    * 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
    Moe Trin, Oct 21, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.