On Fri, Sep 19, 2003 at 12:00:00AM -0400, Omen Wild wrote:
> same server, one through each interface.  To make matters even more
> fun, the DMZ and external clients will get access through a FreeS/WAN
> VPN.

Yeah, that doesn't really sound like the ideal situation for Coda at the
moment.

The main problem we have in this case is that when a client asks for the
location of a volume, the server responds with a single ip-address.

So when your volume was created,
During startup the server does something like,
    for name in /vice/db/servers { gethostbyname(name) }

and picks the first ip-address in the result. Then when a volume is
created (or actually the binary volume replication and location
databases are built, this address is then stored in the VRDB and or
VRDB. From that point on when a client connects it goes like,

    send bind request to server
    receive bind response from server
    send getrootvolumename to server
    receive name of rootvolume 
    send getvolumeinfo(rootvolume) to server
    receive (volumename/volume-id/ip-address)
    connect to the ip-address that holds a replica for this volume.

> 22:55:49.992724 192.168.2.11.32940 > 192.168.1.1.codasrv: udp 297 (DF)
> 22:55:49.996385 192.168.2.1.codasrv > 192.168.2.11.32940: udp 80 (DF)

Ehhh, weird, but as long as the packets are getting back this is ok.

> The client I am testing from is 192.168.2.11, accessing through the DMZ
> interface, through IPSec.
> 
> I get about 10 copies of this error in SrvLog
> 23:13:36 client_GetVenusId: got new host 192.168.2.11:32945
> 23:13:36 Building callback conn.
> 23:13:36 Callback message to 192.168.2.11 port 32945 failed RPC2_NOTCLIENT (F)
> 23:13:36 Worker1: Unbinding RPC connection 452227915

Ok, after the initial exchange I listed above, we continue like this.

    client -> volume-server	NewConnectFS(rootvol)

    server -> client		setup callback connection
    client -> server		ack callback connection
    server -> client		callback message (to test the connection)
    client -> server		ack.

    server -> client		ack NewConnectFS successful

Now because the client believes the server it is talking to is
'192.168.1.1', it believes that the incoming callback connection request
from '192.168.2.1' is really an imposter who is trying to get in. So it
will basically ignore the 'bad' server. Clients only identify a server
by a single ip-address, which is used as the index to find outgoing
connections and to identify incoming connections.

This indexing will already have to change significantly for the IPv6
stuff, maybe at some point a situation like this will just work. But at
the moment the server will have to explicitly bind to the 192.168.1.1 
ip-address.

I believe you have to set both of the following options in
/etc/coda/server.conf,

    hostname=server-hostname
    ipaddress=192.168.1.1
    
where server-hostname is the one used in /vice/db/servers and
/vice/db/vicetab. (ipaddress doesn't do anything until the hostname is
forced to some value)

As a result the server should explictly bind it's listening UDP socket
to 192.168.1.1:2432 (instead of using *:2432), you can check that with
netstat -au. I don't know how this works with routing, but I believe it
might work as long as ip-forwarding is enabled in your kernel.

For some strange reason it would be a lot easier if your server was on a
separate machine on the local network (192.168.1.2) because then the
kernel really just routes the packets and isn't messing around with the
source ip-address of outgoing packets.

Jan