[OpenAFS] AFS over NAT

[Nathan Davis]

Derek Atkins wrote:

> This wouldn't work if you encrypt the RPCs, becuase this AFS-NAT box
> would have to change the _contents_ of a number of the RPCs instead of
> just being a forwarder.  The filserver would still be advertising the
> wrong IP, and that would need to get fixed.

Under what circumstances are RPCs encrypted?  Would it be possible to go encrypted
between the client and the gateway box, then unencrypted between the gateway and the
server?


>
> The right approach is to not use NAT...  Or use ipv6 (not that AFS
> supports that, yet, but getting AFS to support ipv6 is probably a more
> useful use of your time than creating a NAT filter that can't work).

I do not see anything wrong with NAT.  However, whether or not the use of NAT is "right"
or not is not pertinent to this discussion.  The *reallity* is that NAT is used.
Perhaps ipv6 would be a better long-term solution, but I don't recall anyone asking on
the list about when ipv6 support.  I *do* see several questions related to NAT issues.
Hence I proposed a solution for the problem.

Also, I do not see this solution as strictly limited to NAT.  A gateway might be useful
in certain other situations, for example if you want to limit (for security reasons)
remote access to certain volumes on the cell.


>
> -derek
>
> Nathan Davis <davisn@mailandnews.com> writes:
>
> > 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
> >
> >
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info