Re: Login client

[Christian Limpach <chris@Nice.CH>]

> As I said, you have to use real IP addresses, even by forwarding specific
> ports from the gateway in order to let CyberLogin talk to the server (as
you
> did).
> The bytes you receives are from the EOL proxy trying to connect to yours.
> The problem is that the IP packets received by sattelite are destined to
the
> REAL IP used (of the gateway). You may try to enable routing on the
receiver
> PC, to get them sent to the gateway which will (hopefully) de-masquerade
> them and have them sent back to the said PC. It looks rather messy (and
some
> roadblocks can appear).

I couldn't get this to work but that was because my NAT machine will only
de-nat packets which arrive on the correct interface.

I use the following setup:
NAT machines external ip address = a.b.c.d
add alias on NAT machines internal interface: a.b.c.1 netmask 255.255.255.0
add alias on machine with the DVB card: a.b.c.d netmask 255.255.255.0
add routes on machine with the DVB card: route add -host proxy-ip netmask
255.255.255.255 gw a.b.c.1
have your NAT machine forward udp packets it receives on port 8000 to the
machine with the DVB card
use the alias device in CyberLogin.ini (most likely eth0:1 if this is your
first alias)
I think the default gateway on your external segment must not be in the
a.b.c.0/255.255.255.0 ip-space.  If it is and it doesn't work because of
this, you can try to use a narrower netmask or try to use a 255.255.255.255
netmask for the a.b.c.1 alias...
This works if your NAT machine will not touch packets which already have
external ip addresses.
This works because you only need to get packets through your NAT machine in
one direction.
This works because the TCP-stack is smart enough to choose the sender
address depending on the route it uses to send the packet...
The machine with the DVB card can run Linux or Windows, I use it with
both...  Setting up the alias on Windows a little tricky...
It's a gross hack and I can't wait to get a dedicated IP for my DVB
machine...

> Using proxy authentification for masqueraded connections looks a lot more
> cleaner and is described in detail on the web (there is a link earlier on
> this list).

definitely!

    christian