You are not logged in.

Pages: 1

#1 2013-06-27 03:14:52

imatechguy
Arch Linux f@h Team Member
Registered: 2010-03-22
Posts: 66

[SOLVED] iptables blocking nfs connection

I've been trying for some time to set up NFS shares and I have reached a bit of an impasse.  My issue is that if the iptables service on the Server machine is stopped I can use showmount -e <server ip> from the client to get a list of locations from the exports file on the Server side and even mount the locations normally.  However with the iptables service started I get the following error:  "clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused)".

I have the rpc-idmapd and rpc-mountd services running on the Server side, I've bound mountd and nlockmgr to static ports (745 and 4001 respectively).  I've added rules to the bottom of the iptables.rules file to allow tcp and udp traffic on the standard 111 and 2049 ports as well as on the 745 and 4001 ports.  I've stopped and restarted the iptables service on the Server machine, rebooted the Server machine and the connecting machine (my desktop) all to no avail.  At this point I think I've done everything that should enable nfs connections through the Server side iptables firewall.  The only potential issue I see is that "rpcinfo -p" doesn't return a port for the status service but that looked to be related to version3 of NFS and if that was really the issue I think it would prevent connections even with the iptables service stopped.

So I'm curious what I should be looking for as a solution to the problem and what are the indicators I'm not seeing that tell me where/what is the real issue.


All commands run on the Server side machine.

$ systemctl status rpc-idmapd rpc-mountd
rpc-idmapd.service - NFSv4 ID-name mapping daemon
   Loaded: loaded (/usr/lib/systemd/system/rpc-idmapd.service; enabled)
   Active: active (running) since Tue 2013-06-25 21:27:47 CDT; 8min ago
  Process: 470 ExecStart=/usr/sbin/rpc.idmapd $IDMAPD_OPTS (code=exited, status=0/SUCCESS)
 Main PID: 471 (rpc.idmapd)
   CGroup: name=systemd:/system/rpc-idmapd.service
           └─471 /usr/sbin/rpc.idmapd


rpc-mountd.service - NFS Mount Daemon
   Loaded: loaded (/usr/lib/systemd/system/rpc-mountd.service; enabled)
   Active: active (running) since Tue 2013-06-25 21:27:47 CDT; 8min ago
  Process: 469 ExecStart=/usr/sbin/rpc.mountd $MOUNTD_OPTS (code=exited, status=0/SUCCESS)
 Main PID: 472 (rpc.mountd)
   CGroup: name=systemd:/system/rpc-mountd.service
           └─472 /usr/sbin/rpc.mountd -p 745
$ rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049  nfs_acl
    100227    3   tcp   2049  nfs_acl
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl
    100021    1   udp   4001  nlockmgr
    100021    3   udp   4001  nlockmgr
    100021    4   udp   4001  nlockmgr
    100021    1   tcp   4001  nlockmgr
    100021    3   tcp   4001  nlockmgr
    100021    4   tcp   4001  nlockmgr
    100005    1   udp    745  mountd
    100005    1   tcp    745  mountd
    100005    2   udp    745  mountd
    100005    2   tcp    745  mountd
    100005    3   udp    745  mountd
    100005    3   tcp    745  mountd

iptables.rules entries on the server side

<snip>
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A UDP -p udp -m udp --dport 53 -j ACCEPT
COMMIT

Thanks.

Last edited by imatechguy (2013-06-27 14:32:57)

Offline

#2 2013-06-27 04:45:22

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

<snip>
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A UDP -p udp -m udp --dport 53 -j ACCEPT
COMMIT

Don't snip when dealing with iptables rules; post everything please

And to ask the obvious, your NFS client is within the 192.168.0.0/19 address space?

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#3 2013-06-27 05:45:35

imatechguy
Arch Linux f@h Team Member
Registered: 2010-03-22
Posts: 66

Re: [SOLVED] iptables blocking nfs connection

Yes the client is in that IP range; as proof of that my ssh connection functions perfectly.

I've already tried moving the -p option in the string to after the -s option so it would mimic other entries but there was no difference in connectivity.  I've also tried adding the -i eth0 option after the -s option as in other entries just to try something different and that had no effect either.  Note I am stop and starting the iptables service after any change.

current full iptables.rules 

$ cat /etc/iptables/iptables.rules
# Generated by iptables-save v1.4.8 on Mon Jan  3 23:53:05 2005
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [7:1196]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m tcp --dport 32537 -j ACCEPT 
-A INPUT -s 127.0.0.0/19 -i eth0 -j DROP 
-A INPUT -i lo -j ACCEPT 
-A INPUT -m conntrack --ctstate INVALID -j DROP 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p udp -m multiport --dports 137,138 -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m multiport --dports 135,139,445 -j ACCEPT 
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -j REJECT --reject-with icmp-proto-unreachable 
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT 
-A UDP -p udp -m udp --dport 53 -j ACCEPT 
COMMIT
# Completed on Mon Jan  3 23:53:05 2005

previous iptables.rules

$ cat /etc/iptables/iptables.rules
# Generated by iptables-save v1.4.8 on Mon Jan  3 23:53:05 2005
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [7:1196]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m tcp --dport 32537 -j ACCEPT 
-A INPUT -s 127.0.0.0/19 -i eth0 -j DROP 
-A INPUT -i lo -j ACCEPT 
-A INPUT -m conntrack --ctstate INVALID -j DROP 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p udp -m multiport --dports 137,138 -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m multiport --dports 135,139,445 -j ACCEPT 
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -j REJECT --reject-with icmp-proto-unreachable 
-A INPUT -p tcp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -p udp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -p tcp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -p udp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -p tcp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -p udp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 4001 -j ACCEPT
-A INPUT -p tcp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 46318 -j ACCEPT
-A INPUT -p udp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 46318 -j ACCEPT
-A INPUT -p tcp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A INPUT -p udp -s 192.168.0.0/19 -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 745 -j ACCEPT
-A TCP -p tcp -m tcp --dport 80 -j ACCEPT 
-A UDP -p udp -m udp --dport 53 -j ACCEPT 
COMMIT
# Completed on Mon Jan  3 23:53:05 2005

Thank you.

Offline

#4 2013-06-27 07:02:29

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

-A INPUT -p udp -m conntrack --ctstate NEW -j UDP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p udp -m multiport --dports 137,138 -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m multiport --dports 135,139,445 -j ACCEPT 
HERE ===> -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable 
HERE ===> -A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -j REJECT --reject-with icmp-proto-unreachable 
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT

iptables rules are processed in order; the lines I've marked above REJECT the packets before ever getting to your ACCEPT rules.

To resolve, move the ACCEPTs into the respective "TCP" and "UDP" chains, or move the REJECTS to the very bottom of the INPUT rules.

Last edited by fukawi2 (2013-06-27 07:03:36)

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#5 2013-06-27 14:29:10

imatechguy
Arch Linux f@h Team Member
Registered: 2010-03-22
Posts: 66

Re: [SOLVED] iptables blocking nfs connection

fukawi2 wrote:
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p udp -m multiport --dports 137,138 -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP 
-A INPUT -s 192.168.0.0/19 -i eth0 -p tcp -m multiport --dports 135,139,445 -j ACCEPT 
HERE ===> -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable 
HERE ===> -A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 111 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p tcp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT
-A INPUT -s 192.168.0.0/19 -p udp -m conntrack --ctstate NEW,RELATED,ESTABLISHED --dport 2049 -j ACCEPT

iptables rules are processed in order; the lines I've marked above REJECT the packets before ever getting to your ACCEPT rules.

To resolve, move the ACCEPTs into the respective "TCP" and "UDP" chains, or move the REJECTS to the very bottom of the INPUT rules.


Wow, can't believe I kept overlooking that.  Once I moved those two rules, and the third reject line -A INPUT -j REJECT --reject-with icmp-proto-unreachable directly underneath them to the bottom of the file.  Thank you very much for you help.

Last edited by imatechguy (2013-06-27 14:32:22)

Offline

#6 2013-06-27 22:52:53

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

You're welcome smile

imatechguy wrote:

...and the third reject line -A INPUT -j REJECT --reject-with icmp-proto-unreachable directly underneath them to the bottom of the file.

This one won't have been impacting your NFS at all, but it of course makes sense to keep the REJECTS together at the end smile

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#7 2013-06-28 01:46:21

imatechguy
Arch Linux f@h Team Member
Registered: 2010-03-22
Posts: 66

Re: [SOLVED] iptables blocking nfs connection

fukawi2 wrote:

This one won't have been impacting your NFS at all, but it of course makes sense to keep the REJECTS together at the end smile

But it did impact it somehow.  I moved only those two entries you specified, restarted the iptables servcie and I was still unable to use showmount to see the list of available shares with iptables active.  So when I noticed that third reject rule I moved it to the bottom of the iptables.rules file (keeping the rules in the same order), restarted the iptables service again and showmount was able to bring up the list of available shares.

Offline

#8 2013-06-28 02:23:38

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

That's strange; AFAIK NFS doesn't use ICMP for anything....  I'm going to go hit Google now....

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#9 2013-06-28 02:27:58

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

I can't find anything that says NFS needs ICMP; I'm curious to see a tcpdump of the traffic between the hosts when you're mounting. Only for my own learning if nothing else smile

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#10 2013-06-28 03:58:41

imatechguy
Arch Linux f@h Team Member
Registered: 2010-03-22
Posts: 66

Re: [SOLVED] iptables blocking nfs connection

I had to google a bit but here you are.  SSH traffic has been filtered out and I just ask that you explain it to me once you work through it.  If you need more I can dump this into a file so just say how long you want me to let it run for and I'll rerun it.

Steps to create:
1. run tcpdump not port 32537 as root on the server side machine
2. mounted an NFS share on the client side machine
3. ctrl+C to stop the output on the server side machine

# tcpdump not port 32537
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:42:56.881223 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:42:58.881316 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:43:00.881404 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:43:02.881500 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:43:04.076408 IP 192.168.10.131.953 > Serverbox.HOMESERVER.shilp: Flags [S], seq 3815873930, win 14600, options [mss 1460,sackOK,TS val 12141677 ecr 0,nop,wscale 7], length 0
22:43:04.076454 IP Serverbox.HOMESERVER.shilp > 192.168.10.131.953: Flags [S.], seq 394966112, ack 3815873931, win 14480, options [mss 1460,sackOK,TS val 12140474 ecr 12141677,nop,wscale 7], length 0
22:43:04.076536 IP 192.168.10.131.953 > Serverbox.HOMESERVER.shilp: Flags [.], ack 1, win 115, options [nop,nop,TS val 12141677 ecr 12140474], length 0
22:43:04.076854 ARP, Request who-has 192.168.10.1 tell Serverbox.HOMESERVER, length 28
22:43:04.076905 IP 192.168.10.131.1316686702 > Serverbox.HOMESERVER.nfs: 40 null
22:43:04.076943 IP Serverbox.HOMESERVER.shilp > 192.168.10.131.953: Flags [.], ack 45, win 114, options [nop,nop,TS val 12140475 ecr 12141677], length 0
22:43:04.076973 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1316686702: reply ok 24 null
22:43:04.077021 IP 192.168.10.131.953 > Serverbox.HOMESERVER.shilp: Flags [.], ack 29, win 115, options [nop,nop,TS val 12141677 ecr 12140475], length 0
22:43:04.077076 ARP, Reply 192.168.10.1 is-at 08:60:6e:ea:59:28 (oui Unknown), length 46
22:43:04.077085 IP Serverbox.HOMESERVER.42917 > dns-redirect-lb-01.peakview.rr.com.domain: 3137+ PTR? 131.10.168.192.in-addr.arpa. (45)
22:43:04.083165 IP 192.168.10.131.1333463918 > Serverbox.HOMESERVER.nfs: 188 getattr fh 0,0/35
22:43:04.083207 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1333463918: reply ok 60 getattr NON 1 ids 0/1248906321 sz 50331648
22:43:04.086504 IP 192.168.10.131.1350241134 > Serverbox.HOMESERVER.nfs: 116 getattr fh 0,0/36
22:43:04.086543 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1350241134: reply ok 76 getattr NON 3 ids 0/24 sz 0
22:43:04.086594 IP Serverbox.HOMESERVER.882 > 192.168.10.131.46097: Flags [S], seq 4182778911, win 14600, options [mss 1460,sackOK,TS val 12140478 ecr 0,nop,wscale 7], length 0
22:43:04.086653 IP 192.168.10.131 > Serverbox.HOMESERVER: ICMP 192.168.10.131 protocol 6 unreachable, length 68
22:43:04.089814 IP 192.168.10.131.1367018350 > Serverbox.HOMESERVER.nfs: 136 getattr fh 0,0/24
22:43:04.089853 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1367018350: reply ok 208 getattr NON 3 ids 0/10 sz 0
22:43:04.090567 IP 192.168.10.131.1383795566 > Serverbox.HOMESERVER.nfs: 140 getattr fh 0,0/22
22:43:04.090601 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1383795566: reply ok 92 getattr NON 2 ids 0/9 sz 0
22:43:04.091025 IP 192.168.10.131.1400572782 > Serverbox.HOMESERVER.nfs: 144 getattr fh 0,0/22
22:43:04.091050 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1400572782: reply ok 108 getattr NON 2 ids 0/9 sz 0
22:43:04.096466 IP 192.168.10.131.1417349998 > Serverbox.HOMESERVER.nfs: 140 getattr fh 0,0/22
22:43:04.096502 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1417349998: reply ok 92 getattr NON 2 ids 0/9 sz 0
22:43:04.099807 IP 192.168.10.131.1434127214 > Serverbox.HOMESERVER.nfs: 144 getattr fh 0,0/22
22:43:04.099836 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1434127214: reply ok 108 getattr NON 2 ids 0/9 sz 0
22:43:04.103148 IP 192.168.10.131.1450904430 > Serverbox.HOMESERVER.nfs: 140 getattr fh 0,0/22
22:43:04.103179 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1450904430: reply ok 72 getattr NON 2 ids 0/9 sz 0
22:43:04.106558 IP 192.168.10.131.1467681646 > Serverbox.HOMESERVER.nfs: 140 getattr fh 0,0/22
22:43:04.106596 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1467681646: reply ok 92 getattr NON 2 ids 0/9 sz 0
22:43:04.107082 IP 192.168.10.131.1484458862 > Serverbox.HOMESERVER.nfs: 144 getattr fh 0,0/22
22:43:04.142715 IP Serverbox.HOMESERVER.54394 > dns-redirect-lb-01.peakview.rr.com.domain: 9737+ PTR? 1.10.168.192.in-addr.arpa. (43)
22:43:04.167016 IP 192.168.10.131.1669008238 > Serverbox.HOMESERVER.nfs: 180 getattr fh 0,0/22
22:43:04.167091 IP Serverbox.HOMESERVER.nfs > 192.168.10.131.1669008238: reply ok 124 getattr NON 3 ids 0/3 sz 0
22:43:04.245135 IP Serverbox.HOMESERVER.40610 > dns-redirect-lb-01.peakview.rr.com.domain: 37388+ PTR? 110.229.85.76.in-addr.arpa. (44)
22:43:04.322334 IP dns-redirect-lb-01.peakview.rr.com.domain > Serverbox.HOMESERVER.40610: 37388 1/0/0 PTR dns-redirect-lb-01.peakview.rr.com. (92)
22:43:04.881593 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:43:06.881691 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
22:43:08.881782 STP 802.1d, Config, Flags [none], bridge-id 8000.08:60:6e:ea:59:28.8001, length 43
^Z
[1]+  Stopped                 tcpdump not port 32537

Thanks.

Offline

#11 2013-06-28 06:41:21

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

Sorry, I should have included that....

tcpdump -lnn -i eth0 host XXX and host YYY

Update eth0 to suit, and change XXX to the server's IP address, and YYY to the client's IP address. Run that, execute the mount command in another terminal, then ^C to stop it.

Last edited by fukawi2 (2013-06-28 06:42:47)

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

#12 2013-06-28 10:09:21

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,489

Re: [SOLVED] iptables blocking nfs connection

@fukawi: Not really a need for a tcpdump. You parsed  too quick/cross-eyed in #6. The third rule imatechguy moved is a catch-all, it is not specifying "-p imcp".

Offline

#13 2013-06-28 10:33:49

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,231
Website

Re: [SOLVED] iptables blocking nfs connection

Strike0 wrote:

@fukawi: Not really a need for a tcpdump. You parsed  too quick/cross-eyed in #6. The third rule imatechguy moved is a catch-all, it is not specifying "-p imcp".

Doh! I did scan that one too quick! Well spotted smile

Last edited by fukawi2 (2013-06-28 10:33:59)

Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?

BlueHackers // fscanary // resticctl

Offline

Pages: 1

Board footer

Powered by FluxBB