Linux IP routing between network segments: help with debugging?

Discussion in 'Home Networking' started by Henry Law, Mar 24, 2014.

  1. Henry Law

    Henry Law Guest

    (I've posted this to the Ubuntu networking forum; I hope nobody will
    mind my posting it here too)

    I'm setting up an Ubuntu server to act as a router between a subsidiary
    network segment and the rest of the LAN. It's running 12.04 server and
    has two NICs, thus:

    MAIN LAN (172.24.0.192/26)
    |
    | 172.24.0.240 (eth1)
    Server
    | 10.18.78.254 (eth0)
    |
    SUBSIDIARY SEGMENT (10.18.78.0/24)
    |
    Test PC (10.18.78.55 by DHCP)

    The Test PC can ping the server and vice versa. The server can ping
    stations elsewhere on the main LAN, and vice versa, but the Test PC
    cannot see any address on the main LAN. Can someone help me diagnose
    this? Details follow.

    I have the two NICs set up in /etc/network/interfaces thus:

    auto eth1
    iface eth1 inet static
    address 172.24.0.240
    netmask 255.255.255.192
    gateway 172.24.0.254
    dns-nameservers 172.24.0.254
    auto eth0
    iface eth0 inet static
    address 10.18.78.254
    netmask 255.255.255.0

    After extensive Googling I've used these policy-based routing commands:

    ip route add 10.18.78.0/24 dev eth0 src 10.18.78.254 table admin
    ip route add default via 10.18.78.254 dev eth0 table admin
    ip rule add from 10.18.78.254 table admin
    ip rule add to 10.18.78.254 table admin
    (There's a "1 admin" table set up in /etc/iproute2/rt_tables)

    I have enabled ip forwarding:
    $ sudo sysctl net.ipv4.ip_forward
    net.ipv4.ip_forward = 1

    My routing tables and rules now look like this:
    $ ip route show
    default via 172.24.0.254 dev eth1 metric 100
    10.18.78.0/24 dev eth0 proto kernel scope link src 10.18.78.254
    172.24.0.192/26 dev eth1 proto kernel scope link src 172.24.0.240

    $ ip rule show
    0: from all lookup local
    32764: from all to 10.18.78.254 lookup admin
    32765: from 10.18.78.254 lookup admin
    32766: from all lookup main
    32767: from all lookup default

    $ ip route show table admin
    default via 10.18.78.254 dev eth0
    10.18.78.0/24 dev eth0 scope link src 10.18.78.254

    (Though netstat doesn't show all this, which is worrying)
    $ netstat -rn
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt
    Iface
    0.0.0.0 172.24.0.254 0.0.0.0 UG 0 0 0
    eth1
    10.18.78.0 0.0.0.0 255.255.255.0 U 0 0 0
    eth0
    172.24.0.192 0.0.0.0 255.255.255.192 U 0 0 0
    eth1

    I'm doing something wrong, plainly, but I have no idea either what it is
    or how to debug it.
     
    Henry Law, Mar 24, 2014
    #1
    1. Advertisements

  2. Henry Law

    Henry Law Guest

    I've fixed this and I'm documenting it here in case someone stumbles
    over it in the future.

    The issue is not that the test PC can't see the main LAN; it's that when
    a host on the main LAN tries to respond to some request from the test PC
    it doesn't know how to get back to 10.18.78.0/24. So it uses the
    default gateway (which is actually the ADSL router on the main LAN
    segment), and the reply packets disappear into the ether.

    Solved by doing "ip route add 10.18.78.0/24 via 172.24.0.240" on those
    hosts on the main LAN which provide services to the 10.18.78.0 LAN.
    (Yeah, there's probably an easier way, but at least I know how to make
    it work now).
     
    Henry Law, Mar 24, 2014
    #2
    1. Advertisements

  3. Henry Law

    Chris Davies Guest

    You may be able to add a Static Route entry on your router, which
    specifies your server as the intermediate gateway.

    You also don't need policy routing on your Test PC; a simple default
    route via the Server should have sufficed:

    route add default gw 10.18.78.254

    Or perhaps some of that was configuration for the Server? I wasn't sure.
    Chris
     
    Chris Davies, Mar 25, 2014
    #3
    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.