Hello Scott,
Here is what I have understood from your mail. Please correct me if I am wrong.
> Okay, I think I've got enough of a summary here now to
> suggest to you some specific Zebedee command lines. As background,
> the setup is as follows:
>
> PC1 PC2 PC3 PC4
> ------------- FW1 <=> Internet <=> FW2 --------------
> LAN1 LAN2
>
> In this model, PC1, PC2 and PC3 are all running Kaboodle
> and have Zebedee client/server capability. LAN1 and LAN2 are behind
> firewalls. PC4 is running a VNC server but not Kaboodle nor Zebedee.
> PC2 and PC3 are connected using Kaboodle's VPN, which I will call
> the "control channel". The control channel uses TCP port 4182 only.
>
> Once the control channel is established, PC2 and PC3 exchange
> their NID with each other. Because of this exchange, two things
> happen: first, the GUI in both LAN1 and LAN2 display the VPN connection
> state. Second, the Kaboodle services (ie, VNC and File Transfer today,
> other things tomorrow) must recognize the remote machines as valid
> "targets". For example, if PC4 is a VNC server on LAN2, then Kaboodle
> on PC3 can administer a VNC session from PC3 to PC4. We need to extend
> this "target awareness" so that the Kaboodle instances on LAN1 also
> recognize PC4 as a valid target for a VNC connection.
>
> Presuming we get all of that right...the VNC data flow would
> look like this:
>
> 0. As soon as the user on PC1 clicks "Connect" in the VNC Window,
> a Zebedee server needs to be started on PC3. Arguably, this server
> should be started as soon as a VPN is started: why else initiate
> a VPN unless you want to do something with it, right? Anyhow...
> PC2 uses the Kaboodle control channel to tell PC3 to activate a
> Zebedee server that's ready to do whatever it, as the Zebedee client,
> tells it to do. The easiest thing to do on PC3 is just this:
>
The problem here is that the zebedee server needs the targethost machine otherwise it redirects all incoming data to ports on the local machine. We need to enable the �Allow loopback connection� for the VNC server if the target machine is same as the zebedee server machine.
> PC3> zebedee
-s
>
> The only problem with this is that this Zebedee
server will do
> anything *any* client tells it to do, even
one initiated from
> some malicious user somewhere. What we
need to do, then, is to
> restrict the IP addresses that
PC3's Zebedee server will accept
> connections from:
>
> PC3> zebedee -s -x "checkaddress a.b.c.d"
>
Checkaddress a.b.c.d (a.b.c.d dynamic ip address which we use for VPNing pc2�pc3 in this case it is PC2 for example)
> In this case,
a.b.c.d is the "real world" IP address of PC2, or
> in other
words, the IP address that valid data from PC2 will be
>
coming from. Of course, IP addresses can be "spoofed", but this
>
is much better than nothing. What would be even better would
be
> if Zebedee on PC3 generated a "shared secret" key on the
fly, and
> sent that key to PC2 using the existing
(encrypted) Kaboodle
> channel. So:
>
>
PC3> zebedee -x "sharedkeygencommand"
>
>
This should create a sharedkey value that is written to stdout.
It
> should be a 32-digit hexadecimal for a 128-bit encrypted
channel,
> but going forward I'll just call it "012345678".
We could then send
> this value to PC2 over the control
channel, and then start the zebedee
> server:
>
> PC3> zebedee -s -x "checkaddress a.b.c.d" -x "sharedkey
012345678"
>
On Pc3 we will create a shared key and pass it to the PC2 through VPN tunnel.
But I could not create the shared key with the command sharedkeygencommand.
> Now the server is started on PC3, but it
will only accept connections
> from a.b.c.d, and then only if
that connection includes "012345678"
> as the shared key
value. Going even further, we could use the -p and
> -P
switches to require the use of public/private key pairs, rather
>
than a shared key. This way, even if the Kaboodle
control-channel
> was broken, and a malicious use intercepted
the key value being
> transmitted, they still wouldn't have
enough information to spoof
> the IP address and connect to
the Zebedee server. But lets just get
> shared key working
first.
>
First we will work with shared keys and then with public and private keys.
> Lastly, please notice that we
could/should have used the -T switch
> the whole
time:
>
> PC3> zebedee -s -T 11965 ...
>
> The -T switch tells the Zebedee server to listen to the
TCP port
> 11965. This happens to be the default for Zebedee,
so it's not
> needed as written. However, it's very important
to note that no
> Zebedee connections will work if the
firewall protecting PC3 doesn't
> allow this TCP port into
the network. Also, if we ever want to change
> what ports
Kaboodle uses for the VPN connection (ie, if we had a
>
user-setable value field somewhere), we'd need to specify this
>
explicitly. So I think we should include it explicitly now
so
> that it's easy to change later (in some "user this TCP
port for
> data from your Engaged Partners" field).
We need to change the zebedee server listening port.
Where will the user specify the port for zebedee server in
the application? If you could tell the exact location I will add it and pass
that information through the VPN tunnel.
>
>
That's it for the server side. The Zebedee server on PC3
will
> now do whatever the Zebedee client on PC2 tells it to
do. Since
> we've secured things regarding who PC2 is, this
should be fine.
>
>
> 1. Now on PC2, we need to start the
Zebedee client which connects
> with this Zebedee server on
PC3. Keep in mind we have to use both
> the -T switch (since
Zebedee on PC3 might be listening to whatever
> the user
chose, the value we know about since it was in the NID
> we
got over the control channel) and the sharedkey value. This
>
client will be tunneling VNC data to port 5904 on PC4, so we need
>
to "open" a tunnel entrance for this data on the loopback
interface
> of PC2. We can use whatever port number we want
on the loopback, so
> lets use "55555". All said, it would
look something like this:
>
> PC2> zebedee -b
127.0.0.1 -T 11965 -x "sharedkey 012345678"
>
ip.addr.of.PC3
55555:ip.addr.of.PC4:5904
>
> Taking this apart, we've
used Zebedee to open a tunnel from port
> 55555 on our
loopback interface of PC2, and any data send there
> will
emerge from PC3 headed for port 5904 on PC4. Note that this
>
is, really, where all the "smarts" are -- setting up the server
>
was a breeze.
>
> 2. Now all we need to do is to get
the VNC viewer on PC1 to connect
> with TCP port 55555 on the
loopback interface of PC2. For this, we
> use Kaboodle's
*existing TCP tunneling capabilities* -- we just
> specify to
that tunnel, when we set it up on PC2, the destination
> that
we want: 127.0.0.1:55555 on PC2. Please note that Zebedee
>
does *not* have to be started on PC1 -- that would be a bit
>
redundant as Kaboodle already does this. We could start another
>
Zebedee server on PC2 and a client on PC1, and make a quick
>
handoff, but it should be easier to stick with what we have
>
working already. If you disagree, the Zebedee commands would
be:
>
> PC1> zebedee
66666:PC2:55555
> PC2>
zebedee -s localhost:55555
>
> In the above, we would
now just need to point our VNC viewer to
> port 66666 on PC1,
and the data would find its way to PC4.
>
> I've
spoken to Neil Winton (the Zebedee developer) and he's
>
interested in the idea of Zebedee being updated to be a "passthru"
>
server, optimized for such things, but that mode doesn't work
yet.
> Me, I think using Kaboodle for "LAN tunneling" and
Zebedee for
> "LAN to LAN" tunneling is easier.
>
> 3. If, instead, we were starting the VNC viewer session on PC2
and
> not PC1, it would be even easier: we'd never even have
to use
> Kaboodle's tunnel. We could instead connect the VNC
viewer on
> PC2 directly to it's own loopback interface, TCP
port 55555.
>
> 4. If, instead, we were using Zebedee to tunnel a
Kaboodle
> file-transfer from PC1 to PC3, most of the above
remains the
> same. The Zebedee server startup on PC3 stays
the same, but
> we'd have to adjust where the tunnel end on
PC3 was pointing:
>
> PC2> zebedee -b 127.0.0.1 -T
11965 -x "sharedkey 012345678"
>
ip.addr.of.PC3
77777:127.0.0.1:7000
>
> Now if Kaboodle on PC3 was
listening to TCP port 7000 for
> file-transfers, it would
hear anything that was written into
> TCP port 77777 on PC2.
We direct the "client" part of the
> Kaboodle file transfer
applet to connect there.
>
>
> In summary, please notice one
key element: all of the data
> transactions between PC2 and PC3 arrive at
PC3's TCP port 11965,
> where the Zebedee server is listening. Even if PC2
opens multiple,
> simultaneous connections to PC3, it all gets stuffed
into the same
> "tunnel". That's the whole point of Kaboodle's VPN
capability.
>
> Please let me know if this
makes any more sense now. Thanks!
>
> -Scott
>
>
>
>
-------------------------------------------------------
> This SF.NET
email is sponsored by: AMD - Your access to the experts
> on Hammer
Technology! Open Source & Linux Developers, register now
> for the AMD
Developer Symposium. Code: EX8664
> http://www.developwithamd.com/developerlab
>
_______________________________________________
> Kaboodle-devel mailing
list
> [EMAIL PROTECTED]
>
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
>
