Hey guys, hoping someone can clarify some things for me, couldn't seem to get a decent answer.

I had iptables setup with just two rules --
My assumption is that would essentially allow all traffic on the local LAN, and nothing else.

Yet with that, if I create an NFS export and restart the NFS service, it totally hangs on NFS Quotas (which aren't configured).

I'm doing this on CentOS 6. I have been able to clear the error altogether by adding this line inbetween the two above --
I guess I thought that line shouldn't have mattered if I'm set to just accept anything coming from the subnet anyways, can anyone teach me something new as to why that is or how iptables works so I can be more efficient in the future?

To the best of my knowledge there is no "DENY" target in iptables.
Are you getting a "target doesnt exist" type error when creating that rule?

You would want to use the DROP, or REJECT targets.

iptables wont make restarting nfs hang. That is most likely a configuration problem with NFS.

I'm sorry, I did that from memory, and you are correct, it was actually a REJECT statement. (I edited the original post to reflect that.)
It isn't going to be an issue with NFS I don't think, considering the entire file contains the one line -
Without iptables on, that works like a champ, if I turn iptables on and I just have the two lines, it hangs.
Seriously, I challenge anyone to try this. I would really like to know.

So it works if you have the NEW,RELATED,ESTABLISHED rule?

I havent had much to do with simplified sets of rules such as this, ive always used full sets of rules that have generally had a REL/EST rule in there anyway. But i THINK it shouldnt matter if you are matching anything from that subnet regardless of its state.

What is the actual problem, that nfs-server wont restart, with iptables rules in place?
or that the client cant connect due to iptables rules?

Try
and trying to connect from the client, then watching the packet/byte counters, to see which rule its hitting, if any.

Yeah, it works fine with that rule in place.

The problem is the service doesn't even start. If you do that first method, and then do an NFS restart, it hangs on 'Starting NFS quotas:', after a few minutes it fails.
Then it goes to 'Starting NFS daemon:' and after a very long time, that fails as well. If you turn off iptables, it works fine.

I don't do many simple iptable configs either, but this was for a special project and thus I would like it clarified somehow so I better know how it works, it just doesn't seem right to me to HAVE to have that other rule in order for this to work.

Edit: Here's the output from after the NFS Daemon fails -
But I still don't understand why that rule allows it the ability to create sockets?

what does iptables -nvL give you?

I dont understand the default RHEL/CentOS iptables setup (RH-FIREWALL whatever it is) these days. As i use my own which is somewhat different.

http://www.centos.org/docs/5/html/De...US/ch-nfs.html

Maybe CentOS 6 is loading some extra firewall rules itself that are blocking rpcbind/portmap, and then you are adding your rules on top of them?

http://forums.fedoraforum.org/showpo...36&postcount=2 may be of some help..

The 'iptables -nvL' just list those two rules under input, all other chains are empty.

The first rule should enable that tcp 2049 deal, I tried creating an explicit rule for it anyways, same result. I also was able to verify that rpcbind is indeed running before I try to restart the service. As this is CentOS 6, it's based off RHEL 6 and using NFSv4 if that helps at all. I didn't see anything new in the Centos manual.

I sincerely thank you for your help regardless fuwaki1, thanks.

Im out of ideas.
If it works with the NEW,REL,EST rule in there, i say let it work. :-P

Maybe someone more knowledge-able than me will chime in

Thanks anyways fukawi, if anyone has any other ideas, I'm completely open, I'd really like to know why that's the case.


Side note: I thought about it a bit more and since sockets are made locally, it would appear it can also work if you add-
That just allows the localhost through the firewall, and that also appears to resolve it, I'm still pretty confused as to why that'd be necessary however because the original fix doesn't allow it through that subnet either, so two difference methods to fix the same issue. Can someone clear it up for me please?

Mavman,

Which ports are you allowing for NFS? All I saw was 2049/tcp.

On researching, you should probably allow the following ports:

sunrpc 111/tcp rpcbind #SUN Remote Procedure Call
sunrpc 111/udp rpcbind #SUN Remote Procedure Call
nfsd-status 1110/tcp #Cluster status info
nfsd-keepalive 1110/udp #Client status info
nfsd 2049/tcp nfs # NFS server daemon
nfsd 2049/udp nfs # NFS server daemon
lockd 4045/udp # NFS lock daemon/manager
lockd 4045/tcp

At the very least, allow 111/tcp, 111/udp, 2049/tcp, and 2049/udp. See if that helps.

But that's the thing, it's allowing everything with a source in that subnet, so all those ports would be included anyways regardless. Also just a quick reminder, I do know that I can fix it by using the state rules or by adding the localhost to it, I just wanted a better explanation on why it works in that fashion because I would have assumed the source rule I listed to be enough.

At this point, it shouldn't hurt to add to the firewall the specifics about tcp/udp and the ports involved. You might HAVE to be specific in this regard, especially since it seems you can't get this running successfully.

You can check the the FW logs to see why you can't get NFS working. You can also run a tcpdump to check this (either on the FW or wherever the NFS service is being run, if this is a remote server...or both).

You might also be able to check to see if there's an issue with NFS itself by looking at the log files. Or, disable the firewall and see if NFS works then (do this to get a good idea if it's a FW issue or an NFS issue).

I can try to test this on one of my test machines.

Again, I can get it to run successfully, just fine, with the '-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT' or the '-s 127.0.0.0/8 -j ACCEPT' commands, which is a lot easier than making a bunch of port rules, I just wanted clarification on why it works in this manner for the purpose of being able to write more efficient firewall rules...

Also, I mentioned that NFS was dumping because of a socket error, in which it failed to create a local socket. Yes it involves binding the port to the IP, but if the IP range altogether is allowed then it shouldn't matter, additionally it's not even a full blown connection between two nodes, just the socket itself cracks up.

There is no issue with NFS, if iptables is disabled then it works fine. Also you don't have to go out of your way to test on your machines, I thank you though. I just was wondering if anyone had any more information as to why the loopback & state rules cleared up issues with just creating local sockets.

I am wondering whether this is to do with packet fragmentation. According to the NFS-HOWTO, NFS will not work unless packet fragments can traverse the firewall.

Er, which source are you getting that from? I'd be interested in a good read if you have something available.


EDIT: http://nfs.sourceforge.net/nfs-howto/ -- Found it, please ignore my ignorance, thanks. :/