NFS server behind a PF firewall
July 2010
Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
About
This site is an effort to share some of the base knowledge I have gathered through all this years working with Linux, FreeBSD, OpenBSD, Python or Zope, among others. So, take a look around and I hope you will find the contents useful.
Recent Entries
Recent Comments

collective.solr 1.0rc1 (Release candidate)
2010-07-30 plone.org releases

Products.cron4plone 1.1.5rc1 (Release candidate)
2010-07-30 plone.org releases

vs.dashboardmanager 0.2.6.1
2010-07-30 plone.org releases

Heads up! OpenBSD now supports multi-byte characters!
2010-07-30 OpenBSD Journal (undeadly.org)

Setting the Focus Distance on the Epson V700 Scanner
2010-07-29 betabug

Gnome Census Released (and Red Hat 16% vs Canonical 1% Flame)
2010-07-29 Ramble on

Cómo conectarse a bases de datos SQLite desde NetBeans
2010-07-29 vaites (dmnet)

Diferencias cambiando de Perl a Python
2010-07-28 blackshell

Monos y cacahuetes
2010-07-28 userlinux.net

No Gazoline
2010-07-28 betabug

[c2k10] (Part 5)
2010-07-28 OpenBSD Journal (undeadly.org)

Cómo evitar fbc_channel=1 con Facebook Fan/Like Box
2010-07-28 vaites (dmnet)

Copyright Nonsense
2010-07-28 Ramble on

New Plone Usergroup in Charlottesville, VA kicks off July 29th
2010-07-28 plone.org news

Redimensionar la ventana de Firefox sin extensiones
2010-07-27 vaites (dmnet)

ἀφορισμός XII: Silencio
2010-07-27 emereci

New committer: Baptiste Daroussin (ports)
2010-07-27 FreeBSD latest news

[c2k10] The Hackathon BBQ (Part 4) - June 25 - July 3, 2010, Edmonton, Alberta, Canada
2010-07-26 OpenBSD Journal (undeadly.org)

Setting up Bacula
2010-07-26 Evilcoder

Plone 4 upgrade coming to plone.org
2010-07-25 plone.org news

So I bought a Scanner
2010-07-24 betabug

FreeBSD 8.1 RELEASED
2010-07-24 Evilcoder

FreeBSD 8.1-RELEASE Available
2010-07-23 FreeBSD latest news

Announcing Tornado 1.0
2010-07-23 Ramble on

Sauna Sprint just around the corner
2010-07-22 plone.org news

April-June, 2010 Status Report
2010-07-22 FreeBSD latest news

O culeiro
2010-07-21 emereci

Limitando usuarios ssh en Mercurial
2010-07-21 userlinux.net

The Wire
2010-07-20 emereci

Comienza la mudanza, nos vamos a Reading
2010-07-18 blackshell

Recent Trackbacks
Categories
OpenBSD (8 items)
BSD (0 items)
FreeBSD (12 items)
Linux (2 items)
Security (3 items)
Python (18 items)
Zope (13 items)
Daily (120 items)
e-shell (8 items)
Hacks (7 items)
PostgreSQL (3 items)
OSX (7 items)
Nintendo DS (0 items)
enlightenment (0 items)
Apache (3 items)
Nintendo Wii (0 items)
Django (23 items)
Music (9 items)
Plone (7 items)
Varnish (0 items)
Lugo (1 items)
Sendmail (-1 items)
europython (7 items)
Archives

Syndicate this site (XML)

RSS/RDF 0.91

16 febrero
2010

NFS server behind a PF firewall

redirecting NFS traffic could be a little bit tricky

Second post entitled something behind some-other-thing, I've wasted all my imagination when I was a child... ;)

Yesterday I found a small problem with NFS while working on this setup:

NFS behind a PF firewall

In the setup, there are 2 Linux-based NAS devices that export a 1Tb share over NFS. Both NAS are in sync so, if one fails, we can mount the other one and users would be able to keep working while the first NAS is replaced.

Both NAS devices are in a Gigabit LAN, connected with one of the network interfaces on a FreeBSD server (subnet 192.168.10.0/24).

On the other side of the server, there was another LAN, where workstations are connected to the server (subnet 192.168.1.0/24).

The plan was to mount the /nfs/shares share in the FreeBSD server and then export it again from the server, allowing the workstations to mount it. It didn't work. After some reading I found out that NFS does not like to re-export NFS shares, that is, if you mount an NFS share from server A on server B and then you try to export that share from the mount point in server B to server C (for example) you will get all kinds of nasty errors.

It was time for a change in the plan. I didn't want to give full-access to the NAS devices and I didn't want the workstations to mount the share directly from the NAS devices either, because if one fails, I would have to modify the mounts in every workstation so they use the backup NAS device.

Perhaps I could use PF in the FreeBSD server to redirect NFS traffic from the workstations directly to the NAS devices...

Well, it took me some time to think about how to do it (and some help from viq at #pf in freenode). The best approach could be some kind of binat that could map the NFS requests for a given ip address to the ip address of the selected NAS device. Anyway, you can't map a whole network (or any to use a wildcard), so binat would not work. I had to think about a different way to do it.

Let's begin modifying the setup a little bit:

NFS behind a PF firewall (final setup)

As you can see in the picture, my idea was to add an alias to the nic connected to the 192.168.1.0/24 subnet, then I would be able to use PF to redirect all incoming traffic for that alias (192.168.1.100) to a given NAS device. As I've a local DNS server in the network I could add an A entry for nfs.mydomain.com that points to 192.168.1.100, this way I would be able to use that internal subdomain instead the ip address to access the NFS shares. Nice, the new plan was finished, let's start it! (I'll omit the DNS Zone modification, as it is out of the scope of this post)

First, I added the alias definition to /etc/rc.conf:

ifconfig_bge0_alias0="inet 192.168.1.100 netmask 255.255.255.0"

This will create the alias properly after a reboot. Then I created the alias manually:

ifconfig bge0 alias 192.168.1.100

Once I've created the alias, I added PF support in /etc/rc.conf:

pf_enable="YES"
pflog_enable="YES"
gateway_enable="YES"

This will load the needed stuff on boot (kernel modules, sysctl knobs, etc). This will work if you've the GENERIC kernel, if not, you will have to check if your custom kernel has pf support enabled within the kernel or as a KLD.

Then I created the /etc/pf.conf file. This is a stripped version of it (It shows only the needed stuff for the NFS redirection to work):

lan_if="bge0" # NIC connected to the Intranet LAN
nas_if="bge1" # NIC connected to the NAS-storage LAN

nfsalias="192.168.1.100" # Local alias to manage requests for NFS storage
mainnas="192.168.10.2" # Main storage NAS
backupnas="192.168.10.3" # Backup storage NAS

rdr on $lan_if proto { tcp, udp } from $lan_if:network to $nfsalias port 111:65535 -> $mainnas

pass in log quick on $lan_if proto { tcp, udp } from $lan_if:network to $mainnas keep state

pass in all
pass out all

What I do with this pf.conf configuration file is set a redirection so all tcp and udp traffic from the workstations LAN to the alias ip on any port between 111 and 65535 will get redirected to the main NAS device.

The reason for such redirect is that NFS uses random ports for connections (in a similar way to what FTP does) so it is easier to open a full-range of ports. The first port is 111 as it is the first port needed by NFS (sunrpc/rpcbind) and, this way, I block requests for the NAS device web interface (port 80) and SSH (port 22) and users from the workstations LAN will not be able to access the management interfaces of the NAS device.

You should have noticed that the following line is not needed at all:

pass in log quick on $lan_if proto { tcp, udp } from $lan_if:network to $mainnas keep state

It is not (because I do a pass all later) but it allows me to log only NFS traffic (useful for debugging).

Ok, once I had everything in place, I started PF:

/etc/rc.d/pf start

(This will load the kernel module if needed, set the proper sysctl options and will enable pf too)

If my plan was right (and it was ;D) I should be able to access the NFS shares of the main NAS device from any workstation, so I did some checks using showmount:

$ showmount -d nfs.mydomain.com
Directories on nfs.mydomain.com:
*,192.168.1.0/24
*,192.168.10.1
/mnt/soho_storage/samba/shares/shares

It worked!. that soho_storage path you see there is the full path of the shares share within the NAS device filesystem. The Iomega NAS stores all the data within a directory called samba/shares and then it creates symlinks of the data within the /nfs directory.

Ok, as showmount worked, it was time for the final test, to mount the share. In FreeBSD workstations I modified /etc/fstab, adding:

nfs.mydomain.com:/nfs/shares /mnt/nfsstuff  nfs     rw,tcp            0       0

In the Linux workstations I added a line like:

nfs.mydomain.com:/nfs/shares /mnt/nfsstuff nfs rw,tcp,rsize=32768,wsize=32768,hard,intr,timeo=14,bg       0       0

Of course /mnt/nfsstuff must exist. With the proper fstab lines in place, I just tried to mount the share:

# mount /mnt/nfsstuff

Which worked as expected:

$ df -h
Filesystem               Size    Used   Avail Capacity  Mounted on

[ stripped ]

nfs.mydomain.com:/nfs/shares    929G    269G    660G    29%    /mnt/nfsstuff

Conclusion:

It was really disgusting to find out that NFS does not support re-export of shares. This is the first time in many years I find something I don't like about NFS. Anyway, I found a great solution, perhaps even better than re-exporting it. With this setup, if the main NAS device fails, I only have to change one PF rule and all the requests for nfs.mydomain.com will go to the backup NAS. If needed, I could even split NFS traffic, sending some workstations to the main NAS and some other to the backup NAS or I could block NFS traffic from certain ip addresses, adding some security to the whole thing. IMHO this is a great solution.

Posted by wu at 14:01 | Comments (7) | Trackbacks (0)
<< tracd behind an apache2 proxy | Main | A sysadmin life, everyday is like this >>
Comments
XXXX behind YYY posts!!

How about a "Queimada behind a good dinner" post, to make it 3 in a row???

Posted by: betabug at febrero 17,2010 10:02
Re: XXXX behind YYY posts!!

Yupp, you are right, I should have posted something about the trip to athens... lazy guy I am! ;)

Posted by: Wu at febrero 17,2010 12:29
Re: XXXX behind YYY posts!!

Nonono, don't worry, post about the trip whenever you really want to. I was suggesting to make a post about Queimada in general! Maybe with a recipe :-)

Posted by: betabug at febrero 18,2010 09:52
Re: NFS server behind a PF firewall

You can configure NFS services to use fixed ports (in fact, portmap it's kinda useless then :D).

It's "the preferred way to pass NFS through a firewall(tm)".

Posted by: Juanjo at febrero 18,2010 18:46
Re: NFS server behind a PF firewall

Hey Juanjo!, I hope everything is ok at exeter ;).

I know I can use fixed ports (I've done it before in my servers) but the problem with it is that this Iomega NAS isn't *that* manageable. You can't do that from the web interface and if you do it directly connecting to the device through SSH, any changes you do on the config files will be rewritten on reboot (unless you have a chance to add it to the XML configuration files generated by the web interface).

IMHO, the Iomega devices are more "oriented" to people using windows and mac workstations which would use Samba directly, the NFS stuff is just an addon "just-in-case" :(

Posted by: Wu at febrero 19,2010 09:51
Re: NFS server behind a PF firewall

NFS re-exporting it's possible (in linux) using nfs-user-server.

I used this approach to solve a problem some years ago.

Posted by: Roberto at febrero 19,2010 22:56
Re: NFS server behind a PF firewall

Iomega is a good name in storage, been using Zip drives and such for years. We have some Iomega NAS devices reviewed at our site.

What I really like are the ReadyNAS units (like the NVX, Ultra, Pro Business Edition). You can sync with RSync and even subscribe to Netgears online backup service - the software is built-in to every ReadyNAS unit.

Takes some of the complication out of it. The ReadyNAS forum is great for support if you have any questions or problems.

Posted by: Roger at Network Storage Tips at julio 27,2010 23:33
Re: NFS server behind a PF firewall

Hi roger, thnx for the comment! I never heard of that ReadyNAS solution before, I'll take a look at those products. Thank you a lot for the information.

Posted by: Wu at julio 27,2010 23:49
Trackbacks
Please send trackback to:http://blog.e-shell.org/227/tbping
There are no trackbacks.
Post a comment