Re: Routing problems

From: pcfixer (brad_at_co-opcu.net)
Date: 09/03/04 

Date: Fri, 3 Sep 2004 09:59:39 -0500

Okay, let me try to draw a little picture here.

 Sprint (.2 & .3) Qwest (.4)
        \ /
            \ /
                \ /
                    \ /
                        \ /
                           |
Linux fileserver---|---Unix
                           |
                Linux firewall router (.1)
                           |
                           |
                cable modem

Okay, now maybe you get the idea. When I was talking about the default
gateway for the printer, I meant that that's where it looked to send packets
when it couldn't find them on the local network (that's my definition of a
default gateway, not an interface). I have yet to see a static routing
table feature in an HP printer. And also, nothing on our network is
accessible from the Internet. Our firewall is sealed tight, not even
allowing telnet connection from INSIDE our LAN, the public IP address on it
rotates on a daily basis, and the cable modem shuts down every night and on
the weekends (high security, obviously). So something like a printer being
routed to an Internet gateway doesn't bother me in the least, as long as it
gets to where it can go.

Okay, as for the two Linux boxes, you can see the other one I was talking
about. It's our main file and applications server and has its own static
routes programmed into it, making it essentially a usable default gateway
for clients on the .1 subnet. The Sprint and Qwest routers all have static
routes programmed in, so traffic from any of the branches to the other
branches should be routed directly, not even touching the Linux firewall.
All the Linux firewall is used for as far as routing goes it giving a
central routing point for all clients on the .1 subnet to access any of the
branches and the Internet, and also route Internet requests from the .4
since it doesn't have its own Internet. And yes, there's only one way out
of the .4, vs. 2 at the other branches and 3 at the main office.

Now, here's something else to consider that I just thought of yesterday
afternoon. I mentioned that the firewall has very tight security, only
being accessible through a local monitor/keyboard instead of over the
network. I'm wondering if it's possible that something in the firewall
configuration is blocking routing requests to local computers from (or
traffic from our computers to) computers on the .4 subnet. It's a far
stretch, but it makes at least a little sense because of the fact that we
can talk to them but they can't talk to us, which is the classic firewall
scenario. If that's the case, how can I determine if that's the problem. I
have almost no experience setting up Linux firewalls.

"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrncjfik5.sa9.ibuprofin@atlantis.phx.az.us...
> In article <10je96blqg3b804@corp.supernews.com>, pcfixer wrote:
> >The problem is simply this. Machines on the .1 subnet (with default
> >gateway set to Linux box) can ALWAYS access machines on the .4 subnet,
>
> and that implies that those boxes on the .4 subnet can reach the .1
> subnet, as communications is a two-way thing. You can say "hello "to
> me, but I've got to know where you are (and how to get there) in order
> to answer your "hello".
>
> >but machines on the .4 subnet can't always access machines on the .1
> >subnet unless they static routes on them to the .4 subnet.
>
> Ehhh, the .4 network has only one way off that subnet, right? Everything
> has to go down the QWorst link, whether going to the world, or the .1
> subnet, or the Sprint connected subnets. I don't do windoze, but the
> routing tables on all hosts on the .4 net need only two (well, three
> if you include the loopback) routes. In the Linux format, this would
> look like
>
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 0.0.0.0 192.168.4.xxx 0.0.0.0 UG 0 0 0 eth0
>
> where xxx is the IP of the QWorst box in that office. The windoze routing
> table is more complex, only because they are trying to "baffle 'em with
> bull***" and including totally useless information trying to scare you
> away. But in reality - the above is all it takes. For local hosts, you
> can talk direct. For everything else, it has to go to the head office
> via the QWorst link.
>
> In the head office, I'm guessing you are using twisted pair (as coax is
> pretty uncommon now). Are you using a hub (where all hosts can "hear" all
> conversations) or a switch (where all can hear _broadcasts_ but otherwise
> only hear packets directed to them). If it's a switch, does it have a
> monitor port? If yes, or if it's a hub or even coax, connect a box to
> listen to "all" traffic, and see if you "hear" all the packets from the
> .4 office that are directed to a .1 address (or the Internet). Can you
> also see the "replies" to those packets? For a *nix box, this listening
> would be done with 'tcpdump' - I suppose ethereal would work on both
> *nix and (with a recompile) on windoze.
>
> >We have an HP laser printer on .1 that we needed to be able to print to
> >from .4, and it was inaccessible. I changed its default gateway to the
> >other Linux box (which has basically identical routing information as our
> >Linux firewall) and it was accessible.
>
> There are three types of gateways (actually routes, but I'm trying not
> to confuse you). They are static, dynamic, and default. At this point
> in the discussion, you need only know that the static and dynamic routes
> lead to specific places - literally, this IP block, or that. The default
> is the catchall - and SUPPOSEDLY leads to everywhere OTHER THAN those that
> exist. In the routing table I showed above, there are two specific
> routes - one to the loopback, the other to the local net. The default
> route (in that case) means that if the packets are not going to the
> loopback, or to the local lan, send the packet to the to the QWorst
> router, and it will (hopefully) do the right thing with it.
>
> Your adding a "default" route to the laser printer is covering for the
> fact that it doesn't know how to send packets back to the .4 net, so
> that (when in doubt) it can (punt - or rather) send the packets
_somewhere_
> in the hope that that gateway will know what to do with them.
>
> If you are used to microsoft's definition of 'default gateway', that is
> actually referring to what we call the interface. Looking at their routing
> tables, you'll see them declaring a default gateway for each route, and in
> every case it's the IP of one interface on this computer - not that of the
> next hop router.
>
> >But I don't want to switch the default gateway for .1 machines to it
> >because then our Internet traffic would be going in and out of a single
> >NIC as well.
>
> Hosts on the .1 net should know that the default (no other known route) is
> the Internet router - BUT THEY SHOULD ALSO know how to reach specific
> networks or subnets that _don't_ involve the Internet. This means you
> should be using static routes on those hosts that will be conversing with
> those other networks/subnets. No, I don't like the idea of the printer
> having access (and possibly vice versa) to the Internet.
>
> >The only difference I can see between the two Linux boxes is the version
> >of Slackware. The one that routes properly is 9.1.0 while the router one
> >is 8.1.0. Could there be a bug in the older version I'm not aware of?
>
> Slightly confused here - are you swapping two boxes? Also, Slackware
> only used x.x version numbers. But if that's Slack 8.1 verses 9.1, they
> are both using a 2.4.x kernel, (8.1 started with 2.4.18, 9.1 could be as
> high as 2.4.26 with updates) but different versions of the basic C
> libraries. That could have an effect - I really don't know, because I
> don't use Slack (or any distribution) with the routing configuration
> you are using. We use all static routes here (except for the default
> route to the world). If you are depending on both boxes to re-route
> packets through the single NIC, there _could_ be a difference, as
> this wasn't the way networking was meant to work. Grepping the patch
> logs and ChangeLogs for the 2.4.x kernels, there are some changes in
> the 2.4.27 kernel, but whether that effects you, I don't know.
>
> Old guy

Quantcast