firewall settings 2007-01-26 - By Nigel Wade
Back
chuck lawrence wrote:
> Rick Stevens <rstevens@(protected)> sez...
>
>>> at installation, I asked for the firewall setting of ssh-only, or so
>>> I believe. I was surprised, then, to find nfs working (I have a
>>> potential nfs client behind a firewall, and I'm trying to create a
>>> test box to troubleshoot before asking for holes in *that* firewall).
>>
>> How do you know NFS was working? The fact that the nfsd daemon is
>> running doesn't mean NFS is functional. Connections need to go through
>> the firewall.
>
> well, I was able to mount the volume from my server. I wanted to see it
> fail before I tried to fix it - only it didn't fail. I could see the
> directories and everything.
>
>> Not necessarily. Again, having portmap and nfsd doesn't mean people
>> can get to your server. If the firewall blocks access to portmap and
>> the daemon, people can't mount your NFS shares.
>
> maybe I wasn't clear before. the host with the alleged firewall is an
> nfs client (as is the problem host). no firewall on the server, but my
> production host can't mount the volume, and my test host can.
>
> to summarize and clarify(?): with my firewall set to ssh-only, the nfs
> client works.
NFS clients don't require you to open any incoming ports, all NFS client
traffic is ESTABLISHED,RELATED. A default policy which allows outgoing
traffic and incoming ESTABLISHED,RELATED will allow NFS clients to mount
remote filesystems. An NFS server needs holes poked in the firewall to
allow NFS traffic.
>
>>> also, with my local firewall running(?), web access works, but is
>>> excruciatingly slow - like 45 seconds to open a page.
>>
>> That's probably because you have DNS blocked as well. Make sure you
>> leave port UDP port 53 open (it might be good to leave TCP port 53 open
>> as well).
>
> makes sense. thanks.
If the client is setup to allow ESTABLISHED,RELATED traffic and not to
block outgoing data then DNS ought to work. The only problem you are
likely to see is with delayed responses due to your DNS servers having
to refer to other sites. If this takes longer than 30s the DNS reply
will be blocked by the firewall (the firewall opens a temporary hole to
allow UDP replies, but this only lasts for 30s). The client will
re-issue the request, which should work as the result is cached, but the
overall effect is occasional delayed DNS requests. There is also the
added problem of nscd which caches DNS, and it also has the bad feature
of caching DNS failures.
I would recommend that you poke a hole in your firewall to allow DNS
replies from your DNS servers on UDP port 53. It shouldn't be necessary
to do this for TCP traffic as the ESTABLISHED rule for TCP will handle
it. Also, drop the cache time for DNS failures in nscd to a low value so
failed DNS lookups can be retried. Look for negative-time-to-live in the
hosts section of /etc/nscd.conf. IIRC, the default is something silly
like 2 minutes.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@(protected)
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Redhat-install-list mailing list
Redhat-install-list@(protected)
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@(protected)
Subject: unsubscribe
|
|
