[OpenAFS-devel] Multiple clients behind NAT
Ethan Tira-Thompson
ejt@andrew.cmu.edu
Fri, 7 Jul 2006 14:09:35 -0400
--Apple-Mail-1-42400583
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
I have a setup where I have a OpenAFS client behind a NAT box (linux
running iptables), and the NAT box itself is also an AFS client (it's
more than *just* a NAT box). As far as I can tell, this is a problem
because both clients use the port 7001 for their outgoing requests,
and so when reply packets come back to that port, the NAT is unable
to determine which packets to keep and which to forward on. (or more
generally, which packets to send to which client)
Back in 2001, there was a message regarding this issue:
http://www.openafs.org/pipermail/openafs-info/2001-January/
000195.html
...in particular, this section:
> Rx presently requires that anything that wants to be a server pick
> a port number up front. I'll be submitting patches later this week
> that allow a server to be started on the "random" port assigned
> when rx_Init(0) is called, which will allow user-mode RXAFS clients
> that use randomly-selected ports.
Was this patch ever integrated? Since all outgoing communication
appears to be from port 7001, I don't think so.
I'm not a huge nat/iptables expert, so perhaps I'm missing
something. I'm guessing there's a way to tell iptables to
specifically watch for port 7001 from the each client, and remap
those to another unique port when forwarding to the public interface
so it can tell the replies to client's messages apart. Would that
work? (I believe that's the suggested workaround in the quoted message)
Is that necessary to manually configure though, or should there be
some smartness to do that automatically already (e.g. what would
happen if two NAT'd machines try to send from the same source port
out to the same host using TCP? Does the NAT box just drop one of
their connections, or does it remap one of their ports on the public
interface? Would it be smart enough to do that with UDP?)
thanks,
-ethan
PS On another topic, it would be nice to have more complete
documentation for afsd options, e.g. the afsd.options file -- the
admin guide (http://openafs.org/pages/doc/AdminGuide/
auagd015.htm#HDRWQ391) does a pretty good with the cache options, but
completely neglects discussion of many other parameters, such as -
fakestat{-all}, stat, daemons, volumes, etc. Some of these are
mentioned on other sites' pages, but there should be some central
documentation that lists all of the parameters.
--Apple-Mail-1-42400583
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><FONT =
class=3D"Apple-style-span" color=3D"#000000"><SPAN =
class=3D"Apple-style-span" style=3D"background-color: transparent;">I =
have a setup where I have a OpenAFS client behind a NAT box (linux =
running iptables), and the NAT box itself is also an AFS client (it's =
more than *just* a NAT box).=A0 As far as I can tell, this is a problem =
because both clients use the port 7001 for their outgoing requests, and =
so when reply packets come back to that port, the NAT is unable to =
determine which packets to keep and which to forward on. (or more =
generally, which packets to send to which =
client)</SPAN></FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
color=3D"#000000"><SPAN class=3D"Apple-style-span" =
style=3D"background-color: transparent;"><BR =
class=3D"khtml-block-placeholder"></SPAN></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" color=3D"#000000"><SPAN =
class=3D"Apple-style-span" style=3D"background-color: transparent;">Back =
in 2001, there was a message regarding this =
issue:</SPAN></FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
color=3D"#000000"><SPAN class=3D"Apple-style-span" =
style=3D"background-color: transparent;">=A0 =A0<A =
href=3D"http://www.openafs.org/pipermail/openafs-info/2001-January/000195.=
html">http://www.openafs.org/pipermail/openafs-info/2001-January/000195.ht=
ml</A></SPAN></FONT></DIV><DIV>...in particular, this =
section:</DIV><BLOCKQUOTE type=3D"cite"></BLOCKQUOTE><FONT =
class=3D"Apple-style-span" color=3D"#000000"><SPAN =
class=3D"Apple-style-span" style=3D"background-color: =
transparent;"><BLOCKQUOTE type=3D"cite"><DIV>Rx presently requires that =
anything that wants to be a server pick a port number up front.=A0 I'll =
be submitting patches later this week that allow a server to be started =
on the "random" port assigned when rx_Init(0) is called, which will =
allow user-mode RXAFS clients that use randomly-selected =
ports.</DIV></BLOCKQUOTE></SPAN></FONT><DIV>Was this patch ever =
integrated?=A0 Since all outgoing communication appears to be from port =
7001, I don't think so.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I'm not a huge nat/iptables =
expert, so perhaps I'm missing something.=A0 I'm guessing there's a way =
to tell iptables to specifically watch for port 7001 from the each =
client, and remap those to another unique port when forwarding to the =
public interface so it can tell the replies to client's messages apart.=A0=
Would that work?=A0 (I believe that's the suggested workaround in the =
quoted message)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Is that necessary to =
manually configure though, or should there be some smartness to do that =
automatically already (e.g. what would happen if two NAT'd machines try =
to send from the same source port out to the same host using TCP?=A0 =
Does the NAT box just drop one of their connections, or does it remap =
one of their ports on the public interface?=A0 Would it be smart enough =
to do that with UDP?)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>thanks,</DIV><DIV>=A0 =
-ethan</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>PS On =
another topic, it would be nice to have more complete documentation for =
afsd options, e.g. the afsd.options file -- the admin guide (<A =
href=3D"http://openafs.org/pages/doc/AdminGuide/auagd015.htm#HDRWQ391">htt=
p://openafs.org/pages/doc/AdminGuide/auagd015.htm#HDRWQ391</A>) does a =
pretty good with the cache options, but completely neglects discussion =
of many other parameters, such as -fakestat{-all}, stat, daemons, =
volumes, etc.=A0 =A0Some of these are mentioned on other sites' pages, =
but there should be some central documentation that lists all of the =
parameters.</DIV></BODY></HTML>=
--Apple-Mail-1-42400583--