Re: Routing problems

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 09/03/04


Date: Fri, 03 Sep 2004 15:29:08 -0500

In article <10jh1muiks9gc5a@corp.supernews.com>, pcfixer wrote:
>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).

OK - just want to make sure we're on the same page.

>I have yet to see a static routing table feature in an HP printer.

I haven't been the printer guy in years, but if that's a JetDirect
card in the printer, they _did_ have such a capability. Most of the
printing setups I've worked with recently are hanging the printer off
some clapped out box (like a 386, or Sun IPX) which acts as a print
server.

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

Weeeelllllll yeah, but, it is a single NIC situation, and it shouldn't want
to be doing routing.

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

So (I'm ignoring the Sprint link, as it's not really involved in this
problem any more) the hosts on the .4 net know that everything is either
local, or reachable through QWorst, and QWorst knows how to distribute
packets here at the main office. That's good.

>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,

But do those clients on the .1 net know to route DIRECT to QWorst when
trying to reach the .4 net, or are they hoping that the default router
will forward them back to QWorst? I'm pretty sure you've stated this
isn't the case. (Sorry - I'm an old guy, and back then, CPU cycles on
the router and bandwidth on the wire were not to be wasted routing back
out the same hose. That's why there is an ICMP type 5 error in RFC791.
Most modern O/S ignore it now because of security concerns, but that's
a different story.)

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

Side note: You might want to put in place some second mechanism to be
able to log into the firewall - even a dumb terminal hanging off the
serial port (see Remote-Serial-Console-HOWTO), in case the keyboard or
monitor go tits up, or the kernel decides to ignore the keyboard. It's
rare, but it happens. I agree that accessing it over the wire is risky.

>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 possible, but only you can determine that. Pull the plug on the
internet wire, and start yanking rules. Does it start working?

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

It's possible. That _probably_ should show up as rules that mention
specific hosts on the .1 or .4 network.

>If that's the case, how can I determine if that's the problem. I
>have almost no experience setting up Linux firewalls.

Slack9.1 - look at thew boot scripts in /etc/rc.d/ and you'll likely
find one called rc.firewall (although things could be run out of rc.local
just as easily). Did you mention if it's IPCHAINS or iptables? No.
If I recall correctly, Slack9.1 preferred iptables, though IPCHAINS
remained available.

Have a look at the Security-Quickstart-HOWTO, which give examples for
both firewalls. Try the command 'iptables -nl' (or 'iptables -nl')
and see what rules you have. The HOWTO also mentions the netfilter
documents (http://netfilter.samba.org should be good).

        Old guy



Relevant Pages

  • Re: eth card setting for dhcp server
    ... > should the setting on the server ethernet card be. ... Your firewall uses it's own gateway. ... Kernel IP routing table ...
    (comp.os.linux.networking)
  • Re: Another Secure FTP thread -- Protection Levels
    ... gateway or proxy system to act as an FTP relay ... firewall) to the remote system. ... He would need to establish his FTP ... connections from the gateway to the remote system while blocking FTP ...
    (comp.protocols.kermit.misc)
  • Re: Another Secure FTP thread -- Protection Levels
    ... through your firewall that is not authorized. ... FTP either restrict what commands can be sent or logging each command ... gateway or proxy system to act as an FTP relay ... between his system and the remote system. ...
    (comp.protocols.kermit.misc)
  • Re: Another Secure FTP thread -- Protection Levels
    ... gateway or proxy system to act as an FTP relay ... between his system and the remote system. ... There would then be two FTP ... firewall) to the remote system. ...
    (comp.protocols.kermit.misc)
  • Re: RRAS - Works on internal network, not past DMZ
    ... > VPN Users would connect directly to the Public interface of the RRAS box. ... The Firewall would need some additional configuration if you ... On the network connections configuration of the RRAS box, ... but the 'multiple gateway' error message has me spooked. ...
    (microsoft.public.windows.server.networking)