I am trying to provide a directory to the outside world through a
firewall via NFS. I can mount the directory from another system, but
when I try to list the contents of the directory the firewall blocks the
communication. I see that the host system is attempting to send data on
port 65535 using the UDP protocol. I have the following firewall rule
that SHOULD match it, but isn't:
/sbin/ipchains -A output -j ACCEPT -i eth0 -p udp --source-port 61000:65535
I have set the local port range to be 61000-65535. My question is, why
is NFS choosing port 65535 to transfer data? Is it using the local port
range? I tried changing the port range and restarting the NFS daemons,
but it still tried to use port 65535.
I know this isn't necessarily a firewall expert group, but have there
been any issues with ipchains/2.2 kernels blocking NFS traffic on port
65535?
Rob
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. http://www.etnus.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Robert Rati <[email protected]> writes:
> I am trying to provide a directory to the outside world through a
> firewall via NFS. I can mount the directory from another system, but
> when I try to list the contents of the directory the firewall blocks
> the communication. I see that the host system is attempting to send
> data on port 65535 using the UDP protocol. I have the following
> firewall rule that SHOULD match it, but isn't:
>
> /sbin/ipchains -A output -j ACCEPT -i eth0 -p udp --source-port 61000:65535
>
> I have set the local port range to be 61000-65535. My question is,
> why is NFS choosing port 65535 to transfer data? Is it using the
> local port range? I tried changing the port range and restarting the
> NFS daemons, but it still tried to use port 65535.
>
> I know this isn't necessarily a firewall expert group, but have there
> been any issues with ipchains/2.2 kernels blocking NFS traffic on port
> 65535?
It's a fragment, which will match with -f in ipchains.
Alternately, you may set the net.ipv4_always_defrag sysctl, or (for
2.4), insmod ip_conntrack.
Phil.
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. http://www.etnus.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Robert Rati wrote:
> I am trying to provide a directory to the outside world through a
> firewall via NFS. I can mount the directory from another system, but
> when I try to list the contents of the directory the firewall blocks
> the communication. I see that the host system is attempting to send
> data on port 65535 using the UDP protocol. I have the following
> firewall rule that SHOULD match it, but isn't:
>
> /sbin/ipchains -A output -j ACCEPT -i eth0 -p udp --source-port
> 61000:65535
Is this an output chain on the client side? Why should that cause the
client to accept a communication on 65535? Happens all the time: client
requests data on port x, declines the response on port x. Go figure.
Without seeing your entire ipchains config (and I wouldn't recommend
posting it), I can't suggest a one-line fix, but somewhere you need
/sbin/ipchains -A input -j ACCEPT -i eth0 -p udp --source-port 61000:65535,
but I wouldn't recommend it. Instead, specify that NFS use a port in
the reserved range (1-1024) and don't open a hole in your firewall where
hackers often lurk.
Check out
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/NFS-HOWTO.html
for how to specify what port NFS is using.
RM
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. http://www.etnus.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs