Hello Scott, Sorry, at present the code for zebedee+VNC is not considering any firewall settings. I haven't added that code as yet. Can you please test the zebedee only for the pc2 (LAN1)--pc3 (LAN2) direct connection through VPN_port (4182) defined in the kaboodle?
I am on vacation on 12 and 13 Sept. Regards, Varsha ----- Original Message ----- From: "Scott C. Best" <[EMAIL PROTECTED]> To: "mailbox" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, September 10, 2002 9:40 AM Subject: Re: [Kaboodle-devel] Re: Kaboodle + zebedee Status > VK: > Heya. Some replies to your replies: > > > > 1. What TCP port(s) does Kaboodle/Zebedee use now? > > > > > I am using port 2001 as Zebedee client listening port and 5991 for VNC > > viewer. > > Sorry, let me ask this differently. If Kaboodle is running > on PC2 and PC3: > > PC1 PC2 PC3 PC4 > ------------- FW1 <=> Internet <=> FW2 -------------- > LAN1 LAN2 > > What TCP ports do I need to open and forward on FW1 and > FW2? Ideally...there's only *one* port needed. True? > > > > > 2. If I have N machines on my LAN running Kaboodle, only one of > > > them can be the "VPN Master". How does your code determine > > > which is the VPN Master? I recall seeing that it's a checkbox > > > in the PropPanel for a Kaboodle device. > > > > > The VPN code has the array of sockets which contents the information > > regarding the networkIDs and Remote IP address for the established VPN > > connections. > > Good idea. > > > > 3. I think Igor can help with this: only the VPN Master should > > > ping the LAN every 5 seconds. Every non-Master device should > > > just listen unless the user hits "Refresh". Otherwise, with > > > 20 Kaboodle instances on a LAN...there's lots of pinging > > > going on. :) > > > > This can be done but what if none of the machine on the LAN is VPNed? > > As above...in order for Kaboodle to VPN, I'll need to open > a TCP port in my firewall. If the firewall does NAT/PAT, I'll also > have to forward that port to one of the Kaboodle machines. So...one > of the PC's on the LAN is *always* the "master", in a way. > > If when Kaboodle starts up and there is no Master on the LAN, > that Kaboodle instance should declare itself the Master. > > > > I have a one more suggestion for the same. In case of the LAN without > > the kaboodle VPNed instance we can just restrict one kaboodle instance > > to do passive network device detection. > > Nah, the other way is better: passive listening doesn't > generate any traffic. And, listening is hit-or-miss anyhow: success > depends on how good the NIC is and how busy the CPU is. So the more > listeners you have, the better chance you'll have at hearing a new > device enter the LAN. Only one device, though, should be the pinger, > and that should be the VPN Master. > > Thanks! > > -Scott > > > > > On Sun, 8 Sep 2002, mailbox wrote: > > > > > > > Hello Scott, > > > > > > > > I have added the code for Zebedee (points 3 and 4 of the specifications for > > > > zebedee integration) in the Wincvs. At present the zebedee path and tightvnc > > > > paths are hardcode in the code. I will change once you finish your > > > > preliminary testing. > > > > > > > > Please install the tightvnc in C:\program files\tightVNC and zebedee in > > > > c:\program files\zebedee. Please enable the "Allow loopback connections" for > > > > tightvnc servers in order to make VNC servers visible in some of cases > > > > listed below. > > > > > > > > > > > > > > > > The zebedee works for pc1-- >pc4 , pc1-- >pc3, pc2-- >pc3, pc2-- >pc4, > > > > pc3-- >pc2, pc3-- >pc1 > > > > > > > > > > > > > > > > Regrads, > > > > > > > > Varsha > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Scott C. Best" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, July 04, 2002 11:47 PM > > > > Subject: [Kaboodle-devel] Kaboodle VPN design review > > > > > > > > > > > > > > > > > > Heyaz. This email is meant for all of the people on > > > > > the development list. It's an overview of how I see the "VPN" > > > > > capability of Kaboodle working, and I need to know if any > > > > > of you see a problem. > > > > > > > > > > After sleeping on the idea, I've come to the decision > > > > > that utilizing the ZeBeDee utility is the best idea for version > > > > > 1.0. It may make sense to revisit this decision later on when > > > > > more resources are available. But given the requirements, the > > > > > budget, and our existing capabilities, it'd be crazy *not* > > > > > to use a utility as stable and well supported as ZeBeDee. Put > > > > > another way, it's ready now and better than what we could come > > > > > up with in any reasonable timeframe (sorry for any hurt feelings > > > > > here...no offense intended). > > > > > > > > > > Unfortunately...I am not sure how to best implement > > > > > the capability I need using ZeBeDee. Let me describe my target > > > > > need first, and then offer some ideas. What I need is this: > > > > > > > > > > PC1 PC2 PC3 PC4 > > > > > ------------- FW1 <=> Internet <=> FW2 -------------- > > > > > LAN1 LAN2 > > > > > > > > > > In this model, PC1, PC2 and PC3 are all running Kaboodle. > > > > > LAN1 and LAN2 are behind firewalls, and only a small handful (I > > > > > think it's doable with 1, but it's easier with 2) of TCP ports are > > > > > opened to PC2 and PC3 (PC1 and PC4 are not externally accessible > > > > > at all -- two firewalls direct all incoming Kaboodle-related data > > > > > for LAN1 to PC2 and for LAN2 to PC3). Presume that PC2 and PC3 are > > > > > connected using the VPN capability that we're now talking about (so > > > > > both ZeBeDee client and server binaries are available to all of the > > > > > Kaboodle instances). PC4 is not running Kaboodle, nor ZeBeDee, but > > > > > it is running a VNC server. Given all that as background, I need the > > > > > following to work: > > > > > > > > > > 1. Two users on PC2 and PC3 can discover each other using the > > > > > existing capabilities of Kaboodle (which now work). > > > > > > > > > > 2. Once IP addresses are discovered, PC2 and PC3 connect with > > > > > each other in some manner. Let's call this piece the > > > > > "Control Channel". Right now, it with some legacy code > > > > > that we custom-developed. Going forward, we may find it > > > > > better to use ZeBeDee for this as well. We support one > > > > > authentication means today; we can add others as we see > > > > > fit (or as the users insist). > > > > > > > > > > 3. Once the control channel is established, PC2 and PC3 exchange > > > > > their NID with each other. Because of this exchange, two > > > > > things need to happen: first, the GUI in both LAN1 and LAN2 > > > > > display the VPN connection state. This works. 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. The information needed to create > > > > > this awareness is definitely in the NID. > > > > > > > > > > 4. Once the NIDs are exchanged and the target awareness is made > > > > > available to all of the services, I should now be able to VNC > > > > > from PC1 to PC4 using a combination of Kaboodle tunnels and > > > > > the ZeBeDee connection (see below). > > > > > > > > > > 5. Importantly, if I am VNC'ing from PC1 to PC4 using this > > > > > capability, I should be able to start a Kaboodle file transfer > > > > > from PC2 to PC3 without interrupting the VNC connection. > > > > > This, I think, will be the trickiest part. > > > > > > > > > > Ideally, this "VPN connection" is secure as possible, so > > > > > it is secured between PC1 and PC2 using Kaboodle and between PC2 > > > > > and PC3 using ZeBeDee (I don't think we can go from PC2 to PC4 > > > > > using all ZeBeDee...but if anyone sees a way please suggest). > > > > > > > > > > The VNC data flow would look like this: A VNC client on PC1 > > > > > connects to localhost port 100 where Kaboodle on PC1 is listening. > > > > > Kaboodle on PC1 sends this data to port 200 on PC2. On PC2, Kaboodle > > > > > is listening to port 200. Kaboodle on PC2 also instructs a ZeBeDee > > > > > client on PC2 to listen to port 201 on the loopback interface. > > > > > Kaboodle takes the data from port 200, decrypts it using the > > > > > existing VNC tunneling capabilities, and pushes that data into > > > > > port 201 on the loopback interface. The ZeBeDee client collects > > > > > this data from TCP port 201 on the loopback interface of PC2 and > > > > > sends it to the ZeBeeDee server on PC3 which is listening to port > > > > > 300 (it knows to listen to port 300 because Kaboodle on PC3 told > > > > > it to). The ZeBeDee server forwards the data it receives on TCP port > > > > > 300 on PC3 to TCP port 5902 on PC4. The ZeBeDee server knows to > > > > > forward the data like this, because the ZeBeDee client on PC2 told > > > > > it to do so when it connected (eg, the ZeBeDee client had a kickoff > > > > > which looks like "zebedee -b 127.0.0.1 PC3 201:PC4:5902"). The > > > > > ZeBeDee client pn PC2 knew to use port 5902 because Kaboodle on > > > > > PC3 had this information in its NID after running VNC server > > > > > discovery on LAN2. The VNC server receives the data, and the > > > > > return path is symmetric. > > > > > > > > > > I think that covers it. Feedback welcome! > > > > > > > > > > cheers, > > > > > Scott > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > Caffeinated soap. No kidding. > > > > > http://thinkgeek.com/sf > > > > > _______________________________________________ > > > > > Kaboodle-devel mailing list > > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Kaboodle-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel > ------------------------------------------------------- In remembrance www.osdn.com/911/ _______________________________________________ Kaboodle-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
