Hey guys and gals, I’m just wondering if NFS across PIX (running AH & ESP) is possible.
The Diagram looks basically like this.



_____            ____       _______________________      ___      _______________________
|2k box| ------|PIX| ----| IPless Bridge running snort |----|PIX|---|Solaris box|
---------          ------      ------------------------------------     ------     ------------------------------


1) Don’t ask me “Why not SAMBA or FTP or ….?”
2) Don’t tell me “NFS is insecure”


This is something I’m doing in my home lab for the halibut. I set my CCIE written in a couple a months so the PIX boxes have to be running NAT/x25. [:)]


Any ideas about which ports to map?
What’s nat gonna do to the VPN encapsulation (Mind you, I can staticly map any ports I want)
Anyone ever mess with NFS on 2k?

I won't tell you that, because NFS isn't insecure.  However, several older implementations were.

No, but I have used NFS for over 10 years.  I assume the Solaris box is going to be the NFS server.  You need to let port 111 (portmapper) and port 2049 (NFS) through your firewall.  Then, it should all work.  For some reason, I think I also had to allow port 635 (mountd) through too.  When in doubt, do a "rpcinfo
-p localhost" on the Solaris box to see what ports all of the services, that portmap knows about, are running on.  I haven't used any of the newer implementations of NFS, but all of the older ones used only UDP.  Some of the newer ones also use TCP.z

If what zoom suggested doesn't work....
Since it is in a lab and you aren't sure how the NFS on w2k works, why don't you get the communication working between w2k and solaris, then add in the PIX?

As far as ports, the "internal" pix filter is a tcp any any established so if the communication is only one way (always connecting from one box to the other) then you should only need to allow ports on the other PIX.  To find out the ports, enable buffer logging and set the level to debug. The logs will show the ports. Worst case you could do a conduit.

Zoom-
The older version of NFS (V2) used 8KB packets and auth very like TFTP(none [:)]) so yeah it was just a bit insecure. You will only encounter it with HPUX < 10, Solaris <2.5, linux < 1.2.2?, BSD <2.

The newer (V3) (RFC 1813) is the only kind you will find on the newer unices.

So here’s how I got it to work.

Under /etc/dfs/dfstab
Share –F nfs /export
Share –F nfs –o rw=me –d MP3z /export/home/mp3z

Ran
/etc/init.d/nfs.server start
and then started on the 2k client.

Installed services for unix
Used pcnfsd for auth (Don’t forget to set uid for me)
65535 == read only no matter what you set –o to.
And then started on the pixies.

520-1
ran
conduit permit tcp host 192.168.1.1
eq nfs host external.ip.farside.bridge

520-0
conduit permit tcp host 192.168.0.1 eq nfs host external.ip.farside.bridge


Then on the PC client
Ran
Mount MP3z
Note: The pixies listen for outgoing portmapper or rpcbind syn frames and take care of it ok. I can tell that the encapsulation for ipsec is working ok via snort.

Bbauman-
I’m gonna set debug tomorrow on the sun side pix and see if I can ditch the conduits. According to the documentation for 4.3 I should not need to do anything other than standard setup because the PIX is ok with NFS... It didn’t work out that way [:(]



Thanks for the help guys