Linux Iptables Allow NFS Clients to Access the NFS Server

Author: Vivek Gite Last updated: May 3, 2017 21 comments

The portmapper assigns each NFS service to a port dynamically at service startup time. How do I allow legitimate NFS clients to access the NFS server using RHEL / Fedora / CentOS Linux 5.x iptables firewall?

You need to open the following ports:
a] TCP/UDP 111 – RPC 4.0 portmapper

b] TCP/UDP 2049 – NFSD (nfs server)

c] Portmap static ports – Various TCP/UDP ports defined in /etc/sysconfig/nfs file.

Configure NFS Services to Use Fixed Ports

However, NFS and portmap are pretty complex protocols. Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote
access, since NFS servers should never be accessible from outside the organization. However, by default, the portmapper assigns each NFS service to a port dynamically at service startup time.

Dynamic ports cannot be protected by port filtering firewalls such as iptables. First, you need to configure NFS services to use fixed ports. Open /etc/sysconfig/nfs, enter:
# vi /etc/sysconfig/nfs
Modify config directive as follows to set TCP/UDP unused ports:

# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=lockd-port-number
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=lockd-port-number 
# Port rpc.mountd should listen on.
MOUNTD_PORT=mountd-port-number
# Port rquotad should listen on.
RQUOTAD_PORT=rquotad-port-number
# Port rpc.statd should listen on.
STATD_PORT=statd-port-number
# Outgoing port statd should used. The default is port is random
STATD_OUTGOING_PORT=statd-outgoing-port-number

Here is sample listing from one of my production NFS server:

LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
RQUOTAD_PORT=875
STATD_PORT=662
STATD_OUTGOING_PORT=2020

Save and close the files. Restart NFS and portmap services:
# service portmap restart # service nfs restart # service rpcsvcgssd restart

Update /etc/sysconfig/iptables files

Open /etc/sysconfig/iptables, enter:
# vi /etc/sysconfig/iptables
Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p tcp --dport 32803 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p udp --dport 32769 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p tcp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p udp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p tcp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p udp --dport 875 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24  -m state --state NEW -p tcp --dport 662 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 662 -j ACCEP

Save and close the file. Replace 192.168.1.0/24 with your actual LAN subnet /mask combo. You need to use static port values defined by /etc/sysconfig/nfs config file. Restart iptables service:
# service iptables restart

This entry is 6 of 15 in the Linux / UNIX NFS File Server Tutorial series. Keep reading the rest of the series:

🐧 If you liked this page, please support my work on Patreon or with a donation.
🐧 Get the latest tutorials on SysAdmin, Linux/Unix, Open Source/DevOps topics:

RSS feed or Weekly email newsletter
Share on Twitter • Facebook • 21 comments... add one ↓

UP NEXT

Category	List of Unix and Linux commands
File Management	cat
Firewall	Alpine Awall • CentOS 8 • OpenSUSE • RHEL 8 • Ubuntu 16.04 • Ubuntu 18.04 • Ubuntu 20.04
Network Utilities	dig • host • ip • nmap
OpenVPN	CentOS 7 • CentOS 8 • Debian 10 • Debian 8/9 • Ubuntu 18.04 • Ubuntu 20.04
Package Manager	apk • apt
Processes Management	bg • chroot • cron • disown • fg • jobs • killall • kill • pidof • pstree • pwdx • time
Searching	grep • whereis • which
User Information	groups • id • lastcomm • last • lid/libuser-lid • logname • members • users • whoami • who • w
WireGuard VPN	Alpine • CentOS 8 • Debian 10 • Firewall • Ubuntu 20.04

21 comments… add one

Christer Edwards Mar 5, 2009 @ 4:22

I know the title specifies using IPtables to allow NFS connections, but I prefer a simpler method. I prefer to use the hosts.allow and hosts.deny files, as the configuration is *much* simpler.

Within the hosts.allow simply set:
portmap:192.168.1.0.

That’s all you need. Because portmap is the lead process, spawning and defining ports for the other services, if you simple limit access to portmap you’ve effectively set the same access restrictions.

Reply Link
🐧 nixCraft Mar 5, 2009 @ 7:50

Christer.

host.allows simply protects only the portmap service itself. It is still possible for attackers to guess the port numbers of NFS services and attack those services directly, even if they are denied access to the portmapper. Combining both iptables and host.allows should provide the better security.

Appreciate your post!

Reply Link
Adam Goryachev Mar 13, 2009 @ 16:06

How do you restart nlockmgr before reloading the iptables firewall? Preferably without breaking the NFS clients that are active….

Regards,
Adam

Reply Link
cmg Nov 23, 2009 @ 16:30

Thanks very much for this, very useful!

Reply Link
cmg Nov 23, 2009 @ 16:46

btw (sorry to post twice in quick succession), I noticed that LOCKD_TCPPORT (32803) isn’t included in your IPTABLES rules.. it is necessary to uncomment this line in /etc/sysconfig/iptables?

Reply Link
🐧 nixCraft Nov 23, 2009 @ 19:58

@ cmg,

Sorry, it was a typo on my part, I’ve updated the faq.

HTH

Reply Link
Eric Pretorious Dec 11, 2009 @ 8:28

BTW, Vivek:

Admin’s will also have to restart the nfslock service in order for rpc.statd and lockd to re-read their configurations.

# service portmap restart
# service nfs restart
# service nfslock restart

[root@vm2 ~]# for x in MOUNTD_ STATD_ LOCKD_ RQUOTAD_ ; do echo "Scripts that containt \"$x...\"" ; grep $x /etc/init.d/* | cut -d':' -f 1 | uniq ; echo ; done Scripts that containt "MOUNTD_..." /etc/init.d/nfs

Scripts that containt "STATD_..."
/etc/init.d/nfslock

Scripts that containt "LOCKD_..."
/etc/init.d/nfs
/etc/init.d/nfslock

Scripts that containt "RQUOTAD_..."
/etc/init.d/nfs

Reply Link
Eric Pretorious Dec 11, 2009 @ 8:32

TCP Wrapper (a.k.a. , libwrap, hosts_access(), and/or hosts.allow & hosts.deny) can be used to restrict access to portmap and to nfs: From the Red Hat Enterprise Linux 5 mountd man page…

rpc.mountd(8) rpc.mountd(8)

NAME
rpc.mountd – NFS mount daemon

TCP_WRAPPERS SUPPORT
This rpc.mountd version is protected by the tcp_wrapper library. You have to give the clients access to rpc.mountd if they should be allowed to use it. To allow connects from clients of the .bar.com domain you could use the following line in /etc/hosts.allow:

mountd: .bar.com

You have to use the daemon name mountd for the daemon name (even if the binary has a different name).

…and according to The Linux NFS-HOWTO all five services can be protected using TCP Wrapper…

The first step in doing this is to add the followng entry to /etc/hosts.deny:

portmap:ALL

Starting with nfs-utils 0.2.0, you can be a bit more careful by controlling access to individual daemons. It’s a good precaution since an intruder will often be able to weasel around the portmapper. If you have a newer version of nfs-utils, add entries for each of the NFS daemons (see the next section to find out what these daemons are; for now just put entries for them in hosts.deny):

lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Reply Link
Roc White Jun 26, 2010 @ 20:27

It seemed the udp port 2049 should also be enabled for NFSD, right?

“-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 2049 -j ACCEPT”

Reply Link
- Han Coumans Sep 5, 2010 @ 9:07
  
  Roc,
  
  In the case of having full control over your clients, who *should* connect over TCP your added firewall rule is not needed.
  But, if you perform a remote install – of CentOS / RedHat 5.5 in my case – over NFS, it is absolutely needed.
  Message on the client after a noticeable delay “That directory could not be mounted from the server.”
  
  I personally believe it’s a bug caused by migration of scripts/config files from RH3 via RH4 to RH5 or maybe earlier already.
  
  For me your post came too late, but nevertheless thanks and a confirm of its need in certain circumstances.
  
  Gtz,
  Han Coumans
  
  Reply Link
- Chris Nord Aug 7, 2012 @ 9:09
  
  Confirmed!
  
  I wanted to boot knoppix via PXE. Knoppix is mounted via nfs and needed udp (this line in /etc/sysconfig/iptables) to work
  
  Thanks!
  
  Reply Link
Gareth Williams Nov 12, 2010 @ 15:52

Vivek,

I just used this fix on Centos 5.5 and it works fine. (I tried Christer Edwards simple solution first and that didn’t). So many thanks.

But – isn’t it horrible to have to do all this just to get NFS working? There is a graphical tool for NFS in Server Settings. I see now this allows fixed NFS ports to be set, if you knew this to be necessary. But I don’t think it fixes iptables. I did use system-config-securitylevel to add the ports – which worked. At the least, there should be a step by step guide on the Centos Wiki. If you don’t mind, I might have a go at that. Thanks again.

Reply Link
Jim Gish Feb 11, 2011 @ 22:54

Do you also need:

-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 2049 -j ACCEPT

>

Reply Link
Neeraj Mar 4, 2011 @ 20:15

Excellent article

Reply Link
Arfat Sep 7, 2011 @ 14:43

Great Article Step by Step.

Reply Link
Bendanan Sep 19, 2011 @ 1:38

Indeed very useful.
The only thing is really to *write* the /etc/sysconfig/nfs file with the lines /xxPORT=/ uncommented! even if the commented values matches the wanted ones …

Reply Link
Bertrand Nov 25, 2011 @ 12:00

On CentOS (and probably RedHat and Fedora), a “newbie” method is to use the graphical tool : “system-config-firewall”

Reply Link
- Bertrand Nov 25, 2011 @ 12:01
  
  OK my bad, should have tested before saying, it doesn’t work so well… :-D
  
  Reply Link
  - Bertrand Nov 25, 2011 @ 12:04
    
    It works ! (if you don’t forget to start services at boot… do not do system being tired…)
    
    Reply Link
Adam Sep 12, 2012 @ 16:45

Hi,

I’m using CentOS 6.2 now, and everything worked, I did add the extra udp 2049 rule which was missed by the author.

But…

the term “RH-Firewall-1-INPUT” did not work, I got this error (line 13 was the first line from this FAQ)

iptables: Applying firewall rules: iptables-restore: line 13 failed

I changed it to “INPUT” and that fixed it.

now my /etc/sysconfig/iptables looks like this:
http://pastebin.com/FLRT8jQK

I guess this changed between centOS 5 and CentOS 6?

Reply Link
loanemu Oct 11, 2015 @ 5:14

Great, thanks for sharing this article post.Much thanks again. Really Great.

Reply Link