Re: Problems with IP forwarding

trevorelbourne_at_gmail.com
Date: 02/10/05

  • Next message: Peter T. Breuer: "Re: Use software RAID where drives are NFS mounts???" 
    Date: 9 Feb 2005 21:33:14 -0800

    prg wrote:
    > Pinging from beaker is not conclusive. The packets _from_ beaker
    > travel a different netfilter path than packets received on an
    > interface. Can your lan boxes ping bunsen? Can they ping beaker's
    > 203.1.78.65 address (though that too is inconclusive of anything)?
    > What does a traceroute to bunsen's GW provide? Where does it stop?

    I cannot ping bunsen from any LAN machine, but I can ping bunsen from
    beaker. I can ping any of beaker's interface from any LAN machine. So:

    PINGS:

    piggy[.12]----->[.3]beaker (WORKS)
    piggy[.12]----->[.65]beaker (WORKS)
    beaker[.65]---->[.66]bunsen (WORKS)
    piggy[.12]----->[.3]beaker[.65]---->[.66]bunsen (FAILS)
    bunsen[.66]---->[.65]beaker[.3]---->[.12]piggy (FAILS)

    > > I am in the process of recompiling my 2.6.10 kernel to turn on
    kprobe
    > > support, and use the netpktlog module to trace packets through the
    > > kernel to see what happens.
    >
    > Unless the kernel you're using now is a home grown compile, I
    seriously
    > doubt that a new effort will provide a fix. RH/FC have included all
    > the routing capabilities in their "stock distro" kernels for years
    now.
    > And googling turned up nothing suspicious about routing code.

    I wasn't looking for a fix by compiling the kernel, just some debugging
    infomation to see what is happening to these packets that are not
    getting through beaker.

    > > Here's some config info:
    > >
    > > BUNSEN (Firewall)
    > > -----------------
    > >
    > > [root@bunsen root]# route -n
    > > Kernel IP routing table
    > > Destination Gateway Genmask Flags Metric Ref
    > Use
    > > Iface
    > > 203.1.78.3 203.1.78.65 255.255.255.255 UGH 0 0
    > 0
    > > eth0
    >
    > This is the only config that looks off. Is this an artifact of
    NATing
    > on beaker? Otherwise, you should have a network route here rather
    than
    > a host route. Ie., 203.1.78.0 (255.255.255.192) rather than
    203.1.78.3
    > (255.255.255.255). That way any packet destined for 203.1.78.0/26
    will
    > have a route via beaker.
    > # route add -net 203.1.78.0 netmask 255.255.255.192 gw 203.1.78.65
    > added after 203.1.78.64 I usually add all my GW routes at the end
    > after all the networks have been entered.

    I agree. I think what I am going to do is to split things into several
    several networks, all in the 10.X.X.X IP space. Allocate 10.0.0.0/24 to
    the LAN, 10.0.1.0/24 to the Firewall/Gateway. All of this sub-netting,
    and using our class C internet IP addresses doesn't make a lot of
    sense.

    > > 203.1.78.224 0.0.0.0 255.255.255.224 U 0 0
    > 0
    > > eth1
    > > 203.1.78.64 0.0.0.0 255.255.255.192 U 0 0
    > 0
    > > eth0
    > > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0
    > 0
    > > lo
    > > 0.0.0.0 203.1.78.226 0.0.0.0 UG 0 0
    > 0
    > > eth1
    >
    > It is tedious but you really need to ping and note responses (or
    none)
    > in the sequence I posted. The idea is to find which box is the
    > culprit, then what about that box is set up wrong. You confirm the
    > culprit by pinging from the other end of the path, ie., from bunsen
    to
    > a lan box.

    I have done this. See above.

    > With your network setup, it may not be possible/reasonable to turn
    off
    > the firewall/filtering rules, but you will save much effort if you
    can
    > confirm that routing works correctly when they are disengaged. Then
    > you know for sure where the problem is. Otherwise, only very close
    > scrutiny and study will likely reveal the key.

    I have even tried turning off our external firewall, very briefly, to
    see if it's the culprit, but it wasn't.

    <snip>
    >
    > BTW, how _are_ you using your network if no packets can get out of
    the
    > lan?

    All of our internal servers live on beaker (mail, samba, etc..) which
    is accessible from the LAN. And, at the moment, we have a proxy server
    set up on beaker for using web, ftp, etc. So it works at the moment.
    But it is quite restrictive.

    Again, thanks for your ongoing help.

    Trevor.

  • Next message: Peter T. Breuer: "Re: Use software RAID where drives are NFS mounts???"