[pfSense] NFS through pfSense
n.schlumberger at gmail.com
Sun May 13 07:03:27 EDT 2012
> 2012/5/12 Michael Schuh <michael.schuh at gmail.com>
> > 2012/5/12 Ugo Bellavance <ugob at lubik.ca>
> >> On 2012-05-11 16:14, Michael Schuh wrote:
> >>> 2012/5/11 Ian Levesque <ian at crystal.harvard.edu
> >>> <mailto:ian at crystal.harvard.**edu <ian at crystal.harvard.edu>>>
> >>> On May 11, 2012, at 2:52 PM, Ugo Bellavance wrote:
> >>> > I'd need to have an NFS client access an NFS server. Both are on
> >>> a different network segment, so I need to have the traffic go
> >>> through the pfSense firewall. Does anyone has the list of ports
> >>> that must be allowed for NFSv3?
> >>> If your client is on the LAN and the server the WAN, you should be
> >>> fine with the built-in state management. If the NFSv3 server is
> >>> behind a firewall, good luck... :) (basically, you'd need to
> >>> configure your server to use static ports, which may not be possible
> >>> with your NAS).
> >> My client is in LAN and the server is on OPT1 (another internal network).
> >> I could do that with my current CheckPoint FW-1, but I needed to allow
> >> ports.
> > Ian pointed it already out....much fun...
> > if:
> > all the clients need the NFS access, they should be in that subnet or the
> > server should be in the subnet of the clients.
> > then:
> > find a solution to get the data shared between the clients and the secured
> > service ( what was the reason why that NFS-Server stands in an DMZ ? )
> > without to open the doors for the entire network.
> > Think about your conceptual design. :-)
> > endif:
> > if:
> > only specific Clients need access
> > then:
> > Allow the traffic from specific ( if not all clients need access)
> > lan-clients to the NFS-Server.
> > Secure up your server, make usage of the local files /etc/hosts.allow,
> > /etc/hosts.deny, cut of (deinstall them completely) all other services,
> > accept only DSA/RSA-Key authentication on SSHv2 and only v2.
> > a word in the documentation : WHY you made that this way. - would be a
> > good idea.
> > Try to keep other Services far from that box.
> > endif:
> > greetings
> > m.
> if it must be NFS - lol:
> may be the simplest solution if the NFS-Server must be in a separate Subnet
> (DMZ) and all Clients needs access to it:
> Create a special SSH-Account on the NFS Server. This NFS-Account has a very
> restricted (at best no) shell, secure him up as ever possbile.
> create the Authentcation keys and allow only Key-Authentication.
> That account has write access to the filesystem share that you like to
> export via NFS.
> Put a second Box in the internal network.
> This box make the NFS-Server for you.
> This box shares the SSH-Fuse-FS (SSHFS) Fileshare mounted from your
> initial server.
> for details please read the certain documentation.
> result is: only a SSH-Connection between internal net and your server.
> all clients connect, read/Write to the internal server.
> both reached. Easy FW-Management and secure NFS-Share.
> drawback: if another application related to the NFS-Server delivers the
> authentication credentials
> you have to manage that this gets applied to the new internal NFS-Server.
> VPN is a solution....ssh tunnel is like an vpn ;-)
eew - works for sure, but why generate some overhead, if you can just define
what ports nfs (and its helper programs) should use.
NFSv3 uses 2 static ports: nfs (2049) and sun-rpc (111)
and 3 dynamic ports (2 for statd, 1 for mountd) which can be defined directly
on the respective daemons. just look for option -p and -o in the man pages.
I have this working on Linux and on FreeBSD.
Depending how you mount your nfs shares, you need to open either tcp or udp
ports, or just open both protocols to keep you life simple.
More information about the List