1. Home
  2. Networking Firewalls
  3. NFS traffic through checkpoint

NFS traffic through checkpoint

So basically the nfs client is trying to establish a connection on using the same information in my firewall (checkpoints state table) ie. the same src address src port dst addr dstr port so the firewall immedietly flags the packet as invalid and drops it, at this point Apache is stuck waiting for a reponse and cannot be interrupted, mount is owned by init so the only way to recover is to reboot, on the host side I notice the following state on my server syn_sent and it pretty much stays in this state forever. When looking at the firewall logs I see tons of dropped packets, i'm not sure if checkpoint is doing some kind of anti synflood detection or its just dropping the packets because they are fragmented or something of that nature if anyone can give me an insight I would be really apreciate it.

This is NFS v3 over TCP and the nfs client is linux 2.4

Reply to
rodrick.brown
Loading thread data ...

Weird. However, before I continue; I find the entire concept of running NFS thrugh a firewall a bit weird. NFS is not at all secure, but with careful design you could probably keep the risks at an acceptable level. From my point of view the far easiest thing to do would be to move whatever is on the NFS server to the web server host and have Apache access it locally.

I know of sites that let web designers/programmers access an internal file server which in turn uses rsync (over ssh) to securely update the web server in the DMZ. If you have similar needs, that might be something to consider.

So, you've got a firewall with a NFS server on one side and a web server on the other side, serving content it accesses over NFS?

The host site you refer to above, is that the NFS server or the web server? Or both hosts? Which connections are stuck in syn_sent? The file requests from web server to NFS server? If so, do you see them at all on the other server?

I've actually seen ethernet switches[1] (which really should know better!) messing up NFS completely when the NFS traffic is high, so I won't be surprised if a more advanced network component could potentially get into trouble with heavy NFS traffic. But that was UDP, not TCP.

A bit more information about:

1) Which server has which symptoms 2) What the firewall actually drops (log) 3) How you opened the firewall up for NFS traffic 4) The netstat output when this happens

and (if possible)

5) tcpdump -n src $The_Other_Host (from both servers)

would probably help...

  1. From D-Link 4 yrs ago, some 8 port 19" gigabit-thingy
Reply to
Eirik Seim

I'm sorry, I wasn't able to parse that.

NFS is not a good protocol to use through a firewall. Firstly it uses RPC, so you need to open a hole for the RPC protocol on port 111.

The mount daemon on the server registers itself with the RPC server, and the RPC server allocates it a port. In principle, this port can be anything in the allowable range 1-65535. The client needs to be able to communicate with mountd in order to mount a filesystem. Secondly, the NFS daemon registers with RPC, and again can be allocated any port in the allowable range. NFS requests to the server need to be sent to the NFS deamon on this port. Whilst these ports will remain fixed for as long as mountd and nfsd keep running, they are likely to change whenever NFS is stopped and started, or the system re-booted.

Some systems have NFS mountd and nfsd which always register themselves at the same port, some do not. For a Linux server, mountd will normally be registered on a secure port, and nfsd will be on 2049 so you'd need to open ports 1-1023 and 2049. In general, to make NFS work consistently you need to open all ports between the NFS server and the NFS client.

Reply to
Nigel Wade

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.