# Host Iptable rule not allowing NFSv4 Cleint connection

## dman777

I have a bridge br0 which runs on my host. I have a kvm guest(192.168.1.5) that is attached to the bridge. I am using NFSv4 to share a filesystem on the host with the kvm guest. But for some reason my firewall blocks a NFSV4 connection with iptables -I INPUT -s 192.168.1.5 --dport 2049 -j ACCEPT.

For troubleshooting I am not running any firewall on the KVM Guest. 

Of course, with the firewall down on the host NFSv4 works with no problems.

----------

## wcg

You could enable the firewall, list all of the DROP

rules with

```

iptable -n -L DROP

```

Then go through the firewall script and comment each

one out individually until you find the one that is blocking

those packets.

If no guilty DROP rule is found, then it would be a FORWARD

rule (to who knows where) or some user-defined chain if

you have anything fancy like that defined.

(Seems kind of crude, but sometimes brute force search

is the fastest way in the face of complexity.)

----------

## Hu

If you do not wish to go through the process described by wcg, then please post the entire output of iptables-save -c.  Seeing one rule is not sufficient to understand the problem.

----------

## dman777

I tried iptables -n -L DROP but it seemed to be a invalid command to iptables. 

On my launch break I went home and trouble shooted some more. Basically, it worked when I deleted the Iptable rule and re-inserted it. Not sure what was diff. this time. When I get home I will investigate more.

----------

## dman777

I compared the rule I reinserted to the rules I have from a older file I iptable-saves to and it's the same exact rule- same exact location. 2nd rule right after accept all from loopback adapter. 

The only other thing I changed was I changed the nfs server daemon from 1 back to default 8(even though there is only 1 client). And I also recompiled nfs-utils to include nfsv3 support in addition to the already nfsv4 support. 

Makes no since why the iptable rule works now but did not before. I find it really annoying as it was 2 days of pain for no reason.

----------

## wcg

```

iptables -n -L DROP

```

Huh, does not work for me either. Seems like that should work,

reading the iptables man page. Another way:

iptables-save -t filter | fgrep -i DROP | fgrep -i INPUT > iptables_drop.list

(This assumes that an ingress filter rule is the problem, a reasonable

assumption with udp, where acks if any will be at application level

rather than part of the network protocol.)

Find those rules in your iptables setup script, comment them out one

at a time, rerun the script, until the packets get through. Then ask

yourself how that rule matches those packets.

If it is some catchall "drop everything else" iptables command at

the end of the script, then you need an iptables command (before

that one) to specifically allow udp in from that nfs client ip address

or subnet to your nfs server host ip address(es) and a reverse iptables

command to let out udp packets from your host nfs server ip address(es)

to those nfs client ip addresses (nfs runs over udp).

edit:

If you find that you need to insert those iptables commands to let in/out

udp traffic between the nfs clients and your nfs server, you probably

want to include the port number that nfsd listens on in the server.

----------

## wcg

I see that with nfsv4, nfs runs over tcp as well as udp now.

(Probably an improvement. I could never see why we should

use a network filesystem that has to re-invent tcp flow

control at application level, with the original nfs over udp

needed to do to be anything remotely like reliable.)

A brief Redhat summary (first Google hit) on the tcp/udp options

for nfsv4:

http://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-nfs-tcp.html

So what I said about isolating the offending iptables rule still applies,

but one needs to check OUTPUT rules that DROP packets as well as

INPUT rules (the packets might be accepted by the server's firewall

but the tcp acks for those packets not getting back to the client).

----------

