Coda File System

RE: CODA Client behind a NAT

From: Tewari, Vijay <>
Date: Fri, 21 Jun 2002 13:33:55 -0700
I apologize, I was not clear. 

Your assumption was right, the client is being masqueraded .

So if I am getting this right I need to have a mapping on the NAT to forward
all packets to the arbitrary port to the client and setup the appropriate
conf on the client.

Is there a way such that I can force the port number for the currently
arbitrary port on the client. This way I can have a static mapping on the
NAT to forward packets to the client.


-----Original Message-----
From: Jan Harkes [] 
Sent: Friday, June 21, 2002 10:55 AM
Subject: Re: CODA Client behind a NAT

On Fri, Jun 21, 2002 at 10:12:05AM -0700, Tewari, Vijay wrote:
> I am attempting to run a CODA client behind a NAT.
> |--------------|       |------|       |------------|
> | CODA Server  |-------|  NAT |-------| Coda Client|
> |--------------|       |------|       |------------|

Ehh, which of the client or server is being masqueraded here?

I'm guessing the client.

If you set 'masquerade=1' in /etc/coda/venus.conf, all outgoing
communication will go from a single (arbitrary) port to port 2432 on the
server. The server recognizes this and will send anything, including
callbacks back to that port. The firewall should know how to forward these

The only thing is that due to not enough communication the firewall
sometimes drops the redirection information. A Linux 'iptables' based
firewall will do this after 2 minutes of seeing the last packet. So there is
another flag for the client, 'serverprobe=' which can be used to force a
probe once every N seconds, which keeps the redirection in the firewall

Some firewalls have problems with fragmented packets. There isn't a complete
solution for this yet, but setting "validateattrs=21" should remove at least
one source of fragmentation.

So I have,

at the end of my venus.conf.

Then getting tokens is something between clog and the auth2 daemon, clog
will send UDP packets to port 370 on the server. The server simply responds.

Received on 2002-06-21 16:35:42