On Thu, Feb 24, 2005 at 03:00:11PM -0800, redirecting decoy wrote:
> I have a new problem. Well, not really a new problem, just newly noticed.
> I can't get my client to connect to my server.

Let's see if I got this right

Client (M2)           Server (M1)                      TestServer (M3)
     |eth0         eth0|      |eth1                  eth1|       |eth0
    10.1.2.254 -- 10.1.2.1   192.168.10.101 -- 192.168.10.102   10.1.3.1 -->

And you used the ipaddress= option to bind the Coda server socket to
192.168.10.101 on M1.

The Linux kernel internally forwards the packet between eth0 and eth1.
However from the logs it looks like that when we try to send the reply
from 192.168.10.101 to an 10.1.2.0/24 address, the kernel doesn't use
192.168.10.101 as the source address. I thought that by explicitly
binding to some address that it should actually use that address as the
source.

In any case, that first message from the client to the server is an
INIT1 packet, the server then responds with INIT2. Because this is
probably a connection to do the initial query we should not see the
additional INIT3/INIT4 authentication handshake. So the connection
would be assumed up as soon as we get the reply.

I'm not sure what the client sends next, might be a NAK to tell
10.1.2.1 to butt out of the conversation with 192.168.10.101.

Now when you changed to ipaddress=10.1.2.1, things seem to work at
first, the server gets our request, and we see the replies. The problem
in this case is probably that when we get to the step where we ask for
when we ask for the volume location we get '192.168.10.101'. Now we try
to bind to that address, and we end up with the same problem that
'10.1.2.1' is trying to interfere with the handshake with '192.168.10.101'.

I don't think this is necessarily iptables related, but it could be that
once the packet mangling modules are loaded in the kernel it always
rewrites the packets as they go out. Also that masquerade rule does
match the packets from the client to the Coda server, but even in the
worst case it should really only mangle the source address in such a way
that the server thinks the packets are coming from a client running
locally and mangle the destination address in the responses to make it
look like the server did not actually send the replies to itself.

In any case we should be able to fix this specific problem with an
additional iptables rule.

iptables -t nat -A POSTROUTING \ # mangle any outgoing packets,
	-i eth0 -s 10.1.2.1 \	 # sent by us on eth0,
	-p udp --sport 2432 \    # which are coming from codasrv/udp,
	-j SNAT --to-source 192.168.10.101 # in such a way that it looks like
					   # they came from 192.168.10.101

Bind the server to 192.168.10.101, and let it think that it's name
matches that 'public address' so that the volume location responses will
also use 192.168.10.101 as the server's address.

Jan