[OpenAFS] AFS over NAT

[Nathan Davis]

Ray Link wrote:

> On Mon, 5 Aug 2002, Derek Atkins wrote:
>
> > Having an AFS _server_ behind a NAT -- well, that can be problematic.
>
> I'll chime in here with some info for Chris, because I've been looking
> to do the same thing with the small AFS cell I run at home...
>
> > First, you can only have one server.
>
> Not really an issue for me, as it's only for a small cell that is not
> mission-critical.  It essentially just serves out home directories and
> user binaries to the webserver, shellbox, and various workstations
> around the house.
>
> If you're not doing anything that needs the redundancy of multiple
> servers and volume replication, this limitation won't affect you much.
>
> > Second, you still have the timeout issue.
>
> Easy enough to fix with any sane NAT box.  My ipchains/ipmasq box does
> this with a single command.  If your Linux NAT box is running ipchains,
> the following will work for you:
>
> /sbin/ipchains -M -S <TCP> <post-FIN TCP> <UDP>
>
> Where the items between the < > are timeouts, in seconds, for TCP
> sessions, TCP sessions after a "FIN" packet is received, and UDP
> sessions.  I believe something around 10 minutes is recommended for
> the UDP timeouts, so as to not break the AFS callbacks.  If you're not
> using ipchains, I'm sure iptables has similar functionality.
>
> > Third, you have to redirect all AFS UDP access from the NAT box to the server.
>
> Easy enough.  People redirect inbound TCP/UDP to various machines all the
> time to run various services from behind a NAT.
>
> > Fourth, you need the server to
> > advertise its 'NAT' address (i.e. the external address) so clients can
> > contact the server.  This last part is probably the most difficult.
>
> Absolutely.  This is the kicker.  This was actually implemented in
> Transarc AFS 3.6 patch 1.  You could put a line in the NetInfo file
> designated as a fake IP address, and the AFS server would hand that
> external IP out to things like 'vos listaddrs' and external AFS
> clients.
>
> The problem with this is, though, that the code that builds the struct
> of IP addresses in the OpenAFS sources doesn't check for those lines
> designated as 'fake' IPs.  This would be easy enough to implement, but
> there are other places in the code that expect that struct to contain
> only valid IP addresses that are associated with interfaces on the
> server.  They would likely barf upon seeing an IP that is not bound to
> a local interface.  It would be neccessary to somehow populate a second
> structure with only the valid IPs, to be used in those places of the
> code.
>
> I've exchanged some email privately with a few individuals about working
> this functionality into OpenAFS, but we're all a little busy, so nothing
> has come of it yet.
>
> So anyways, the first three points Derek mentioned are fairly trivial to
> accomodate, but the fourth is impossible without some changes to the
> OpenAFS code.
>
> ==== Ray Link === University of Pittsburgh CSSD === rlink@pitt.edu ====
>
> For some reason I was confusing "SubGenius" with "GNU" there.
>         - The Cube, Forum 3000
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

What about this:  Instead of playing tricks to advertise the server under a "fake"
address, someone could write an AFS forwarding service.  This would essentially be
a multi-homed host which would simply take AFS client requests from one interface
and forward them to the real AFS servers on the other side ... sort of like NAT for
IP.  To clients on the "outside," it would just look like a cell consisting of a
single host (or perhaps a few hosts), but the "inside" could be as complex as
necessary.  Of course, you could put the "gateway" machine behind the NAT as well,
and use port forwarding if you wanted to.

I think this would be very appropriate for wide area links, because of the
difference in bandwidth.  For instance, an organization could allow local access to
AFS on a private subnet, while still allowing remote clients to connect via the
internet routable AFS gateway.

Given that noone has brought it up here, I am assuming that such software does not
already exist.  However, given the current thread, it seems like there are those
that could use such software.  I think it would be possible (perhaps even fairly
easy) to make this work.  Of course there will be some issues that will need to be
ironed out, but I can't think of any problem that couldn't be overcome with a
little thinking.  I am willing to write such software, but I would require some
finacial support for this to be feasible at this time.  If anyone is interested,
please drop me a line.

--Nathan Davis