On Tue, Feb 01, 2000 at 12:57:20PM -0800, Tom Tarka wrote:
> Jan Harkes wrote:
> > Are you going through a masquerading firewall?
> 
> bingo.
> 
> > The sftp side-effect transfers will not be able to get back to the
> > client. The firewall only knows about the 2430->2432 outgoing
> > connection, but doesn't forward the packets of the incoming sftp data
> > from server port 2433 -> client port 2431.
> 
> fix?  I'm forwarding tcp and udp on 370, 2430, 2431 2432, 2433 using
> ipmasqadm portfw on my firewall, but I've heard of ipmasq "getting confused"
> with regards to connections coming to the outside IP address as opposed
> to it's own IP address.  Or is this another issue?

Ah, but it looks like the firewall is still masquerading the packets. I
believe that it might work when you only have a single client behind the
firewall and use something like,

ipmasqadm portfw -a -P udp -L $firewall_ip 2430 -R $local_ip 2430
ipmasqadm portfw -a -P udp -L $firewall_ip 2431 -R $local_ip 2431

But I haven't used the 2.2 masquerading for a while. This also means
that the firewall itself will not be able to run a Coda client.

> The weird thing is when I connect from a machine on my internal
> network (which, granted, is my ipmasq firewall and could potentially
> have the same issues, but which shouldn't be actually going through
> the firewall) I get the same errors (see below).  In any case, we're
> probably going the VPN route in the near future, so hopefully this
> won't continue to be an issue, but any help/advice would be great!
> 
> Thanks,
>     t
> 
> CLIENT:
> [root_at_agrippa /boot]# venus -init
> 
> Date: Tue 02/01/2000
> 
> 12:50:51 /usr/coda/LOG setup for size 0x87cc7
> 12:50:51 /usr/coda/DATA initialized at size 0x21f31c
> 12:50:51 brain-wiping recoverable store
> 12:50:52 loading recoverable store
> 12:50:52 starting VSGDB scan
> 12:50:52        0 vsg entries in table
> 12:50:52        0 vsg entries on free-list
> 12:50:52 starting VDB scan
> 12:50:52        1 vol entries in table (0 MLEs)
> 12:50:52        0 vol entries on free-list (0 MLEs)
> 12:50:52 starting FSDB scan (833, 20000) (25, 75, 4)
> 12:50:52        0 cache files in table (0 blocks)
> 12:50:52        833 cache files on free-list
> 12:50:53 starting HDB scan
> 12:50:53        0 hdb entries in table
> 12:50:53        0 hdb entries on free-list
> 12:50:53 Kernel version ioctl failed (Inappropriate ioctl for device)!
> 12:50:53 2.3 or later kernels require an updated kernel module!
> 12:50:53 Initial LRDB allocation
> 12:50:53 Getting Root Volume information...
> 12:50:54 Venus starting...
> 12:51:09 fatal error -- vsgent::Connect: (0) failed (-2004)
> 12:51:09 RecovTerminate: clean shutdown

-2004 is RPC2_FAIL, and sadly enough that error is returned from many
places. Hard to pin down what exactly goes wrong, especially since the
server logs seem to indicate that the connection setup was successful.


> SERVER (-d 10):
> 12:41:28 ViceGetVolumeInfo volume = coda.root
> 12:41:28 ViceGetVolumeInfo returns Success, Volume 2130706435, type 3, servers
> 7f000001 0 0 0...
> 0x1016e088 : Cop Pending Manager

Ok, the unauthenticated connection was set up fine, this should be the
point where the client tries to fetch the contents of the rootdirectory
of the rootvolume. i.e. The first SFTP transfer.

My guess is that some firewall rule is tossing packets destined for port
2431 or 2433 in the wrong direction.

Jan