NFS IPtables Troubles

Hello Everybody,

I am currently using an Odroid C2 running the latest LibreElec. I was looking through the forums and saw that the best way to configure iptables was through autostart.sh , otherwise it will not survive a reboot. I am currently using NFS via the storage-Disk.mount feature. It works great when iptables is not present but I cannot get it to work when using iptables.

I should let you all know that I am a noob when it comes to iptables. I have been using ufw for sometime now. My server is configured with ufw and only allows in from specific ip addresses/ports. Again, this works fine when I do not have iptables running on my Odroid.

I have tried many different iptables configurations but I have not been able to get it to work. When I try to access it through Kodi, it times out and does not show that it is mounted. On my server, I allow in on the following port:111,2049,20048

Here is my most recent configuration that I tried: .25 is the server and .40 is the client. Any help would be sincerely appreciated. I do not want to allow any incoming connections to LibreElec but realize that Iptables has to have some input ability. I was using old computers running manjaro Linux before as my media centers. On those computers, I was using UFW and it was configured as "sudo ufw default deny" and it worked great.

iptables -P INPUT DROP    
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p tcp --sport 111 -j ACCEPT
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p tcp --sport 2049 -j ACCEPT
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p tcp --sport 20048 -j ACCEPT
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p udp --sport 111 -j ACCEPT
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p udp --sport 2049 -j ACCEPT
iptables -A INPUT -s 172.16.10.25/32 -d 172.16.10.40/32 -i eth0 -p udp --sport 20048 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p tcp --dport 111 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p tcp --dport 2049 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p tcp --dport 20048 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p udp --dport 111 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p udp --dport 2049 -j ACCEPT
iptables -A OUTPUT -s 172.16.10.40/32 -d 172.16.10.25/32 -o eth0 -p udp --dport 20048 -j ACCEPT
iptables -I INPUT  -i lo -d 127.0.0.1 -j ACCEPT
iptables -I OUTPUT  -o lo -s 127.0.0.1 -j ACCEPT

I was reading about the dynamic ports a little bit but glanced over them because UFW is just a front end for iptables. I figured if those were the ports that I needed for UFW, that they would also work with iptables.

I do not have rpcbind.service going on my server as I believe that it was only needed for older versions of NFS. NFS works without iptables on Libreelec so maybe I am just not understanding something.

That could be it though. I found this forum post which states that NFSv4 was right around the corner last January.

LibreELEC Testbuilds for x86_64 (Kodi 18.0)

I might have to configure it for NFSv3 which means I would probably have to use rpcbind.service.

Anybody know if I am thinking about this wrong? If the NFS shares worked flawlessly without the firewall, does that mean LibreElec supports NFSv4?

I appreciate the response, subzero79. My question to you would be: Why does NFS work great without the firewall if the client opens a random port below 1024? My server is only configured for 111, 2049, and 20048.

Edit: I just read the Arch wiki and I believe I understand it now. In order for NFS3 to work behind a firewall, certain things have to be tweaked. If anybody cares to elaborate further while I'm sleeping, I would appreciate it.

I tried that and it did not work. I also tried this:

/etc/sysconfig/nfs

STATDARG="-p 32765 -o 32766 -T 32803"

This did not work either. My next step is to switch from ufw on my server to iptables to see if that helps. I have to admit that I am feeling pretty lost right now. I still do not have rpcbind.service running. I think I may need that for NFSv3.

Thanks for the response Escalade. I ran the following command to check to see that idmap was fully working:

cat /sys/module/nfsd/parameters/nfs4_disable_idmapping

It returned a Y so it is working. I am thinking that it is just my firewall configuration.

I got it to work with a basic configuration to deny incoming connections. I really was overthinking it. Here is the configuration that I used:

# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow established sessions to receive traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT