firewall settings

Nigel Wade nmw at ion.le.ac.uk
Fri Jan 26 09:51:40 UTC 2007


chuck lawrence wrote:
> Rick Stevens <rstevens at vitalstream.com> 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 at ion.le.ac.uk
Phone :     +44 (0)116 2523548, Fax : +44 (0)116 2523555




More information about the Redhat-install-list mailing list