Opening a Port between VLANS for NFS Share (Tomato Shibby 97)

Discussion in 'Tomato Firmware' started by Herby, Aug 18, 2012.

  1. Herby

    Herby Serious Server Member

    Sorry in advance for the Noob question, or if I posted in the wrong place.

    I am trying to set up a VLAN (br1) for a home web/mail server that can communicate only with the WAN and to a NAS in my main VLAN (br0) using NFS.

    I figured I could forward a port (I believe it is port 2049 for NFS) from my servers local IP address: to my NAS' local IP: but I'm having trouble doing this through the GUI.

    I tried unsuccessfully using these settings in "Port Forwarding > Basic" to see if I could connect to the NAS' web client from a laptop in the other VLAN:

    On: On
    Pronto: TCP
    Scr Address:
    Ext Ports: 80
    Int Port: 80
    Int Address:

    What would be the best way to allow a machine in one VLAN limited communication to a machine in another VLAN?
  2. koitsu

    koitsu Network Guru Member

    I can't help you with the VLAN / bridging configuration, but I can tell you that NFS does not use consistent port numbers. NFS is absolutely, hands down, the worst protocol to try and pass through firewalls. The entire protocol (meaning looking at the big picture) consists of multiple ports -- if I remember right, 4 total -- and 2 of those are dynamically allocated (no way to make them static -- I repeat: no way to make them static). The 4 NFS-related services are:

    * NFS daemon itself -- TCP and UDP port 2049 (yes, both protocols; NFS supports both TCP and UDP, depending on what the client wants)
    * mountd service -- TCP and UDP port number is dynamic (allocated by RPC)
    * stat/lock service -- TCP and UDP port number is dynamic (allocated by RPC)
    * RPC service (known as "rpcbind" or "portmapper", sometimes "sunrpc") -- TCP and UDP port 111

    All of these are necessary for NFS to truly work. Explanation:

    * NFS daemon (nfsd) is what handles the actual NFS I/O and NFS requests itself (e.g. "client wants to read some bytes").
    * mountd is what handles (allow/deny) clients actually issuing an NFS mount request (to mount an NFS filesystem). mountd registers itself (gets it port number) via RPC.
    * stat/lock service is incredibly important, as it handles stat() and file locking-related requests across NFS. Lots of administrators forget about this, then when two NFS clients try to write to the same file simultaneously, corruption occurs. stat/lock srvice registers itself via RPC.
    * RPC service (rpcbind/portmapper) -- handles actual RPC requests, including from daemons that run on the server itself (e.g. mountd and the stat/lock service).

    The RPC service allocates port numbers dynamically. There is no way to say "mountd should always be given port 1298, and stat/lockd should always be given port 1302".

    The best way, hands down, to pass NFS services through a firewall is to simply do it by IP address. Allow access to all TCP/UDP ports by default, and then for services you don't want someone to be able to reach, set those to deny/block/reject (e.g. if the NFS server runs SSH, block TCP port 22). I know from a security perspective this isn't good, but you have no choice here -- NFS was created before any of this technology existed (firewalls were not common then).

    Here is a real-life example of a working NFS server and what ports it listens on, including rpcinfo/portmapper output so you can see what service is associated with RPC:

    root    rpc.lockd  1148  3  dgram  -> /var/run/logpriv
    root    rpc.statd  1145  6  udp4  *:898    *.*
    root    rpc.statd  1145  7  tcp4  *:898    *.*
    root    nfsd      1141  5  tcp4  *:2049  *.*
    root    mountd    1122  7  udp4  *:849    *.*
    root    mountd    1122  8  tcp4  *:849    *.*
    root    rpcbind    1089  13 udp4  *:111    *.*
    root    rpcbind    1089  16 tcp4  *:111    *.*
    Sorry about the formatting -- this forum software COMPLETELY screws up code block formatting at times. I do not know why, but it's infuriating. It's obviously a forum software bug.

    If you want me to provide you official documentation links to all of these services/daemons (specifically for FreeBSD, but Linux uses all of these as well!), let me know as I can do so easily.
    Herby likes this.
  3. Herby

    Herby Serious Server Member


    Thanks for that post, I know very little about network protocols and I would like to learn more.

    Because I know so little I think I'm going to look for something other than NFS as a means of transferring files from the web server to the NAS. With the server already exposed to the world I wouldn't feel comfortable giving it the ability to communicate too easily with my NAS. I may have the server write to/host from internal storage and use Advanced>LAN Access to give my NAS access to server, maybe just use rsync.

    I'm going to have to think this out. My plan was to host personal files and email from a Raspberry Pi using my NAS as storage but I'll have to do more research I guess.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice