on hold

Post by **Rudi De Vos** » 2005-07-06 09:34

On hold until Aug

odontech · Post by **odontech** » 2005-07-07 14:54

Why! This would be such a GREAT product!

Post by **Rudi De Vos** » 2005-07-07 15:03

3 weeks Holliday

odontech · Post by **odontech** » 2005-07-07 15:13

Is there antything I can do to help out while you are out.. I'm very excited about this application and can't wait till it is available as a complete release.

netwolf · Post by **netwolf** » 2005-07-07 23:57

Rudi De Vos wrote:3 weeks Holliday

Have a great time ! You really deserve it

eo · Post by eo » 2005-08-03 01:55

Rudi De Vos,

Are you back from your vacaction? We missed you - hope that your batteries are recharged and ready to tackle SCIII!

Post by **Rudi De Vos** » 2005-08-03 07:40

Yep, back

SCIII design need to be changed.
It should use the same exe as SCII and repeater.

The SSL implementation need to run as a seperate exe and SC connect in loopback. Same on the repetaer site, the SSL part listen to 443 and connect to the standard repeater ports.

This is more flexable and a lot easier to maintain then different SC versions.

redge · Post by **redge** » 2005-11-12 15:10

Rudi,
Can you replace your SCIII_test4.exe by SCIII_test5.exe

http://www.swiss-adsl.net/redge/SCIII_test5.exe
there the file pre-compiled without any change except the winvnc.exe (6 october 2005) based on online creator RC1.0.0

http://sc.uvnc.com/sciii/SCIII_test5.exe

Thank you a lot

kronos5150 · Post by **kronos5150** » 2005-11-23 20:47

Rudy:
This version seems to based on the OpenSSL source ?

I noticed them .pem file.

Are combining something similar to Stunnel/OpenVPN with VNC ?

Long time Admin / Newbie Coding ...

Just curious ..

posbis · Post by **posbis** » 2006-01-05 21:12

Rudi De Vos wrote:Yep, back

SCIII design need to be changed.
It should use the same exe as SCII and repeater.

The SSL implementation need to run as a seperate exe and SC connect in loopback. Same on the repetaer site, the SSL part listen to 443 and connect to the standard repeater ports.

This is more flexable and a lot easier to maintain then different SC versions.

Basically a good idea but this doesn't mean that two different executables are required for SC-III/Repeater/Viewer. You can do the local loopback inside a single executable and have a command line option (e.g. -ssl) for repeater/distributor which activates the SSL listener in front of the normal listener.

It will become too confusing for not so experienced users when there exist multiple executables which must be started in a correct order.

Post by **Rudi De Vos** » 2006-01-05 21:59

Enduser release use 2 threads, in one exe via loopback.

But during development 2 exe are just a lot easier.

posbis · Post by **posbis** » 2006-01-07 03:20

Rudi De Vos wrote:Enduser release use 2 threads, in one exe via loopback.

But during development 2 exe are just a lot easier.

I see... Cool..

BTW, I was surfing around in this forum and I have one question.

Is there any Roadmap or Release Schedule for the different products

- UVNC 2 Viewer
- UVNC 2 Server
- New Repeater or Distributor
- SC-III

I can't see any timetable for a new release. One week, one month, one year ?

Just asking ...

Another thing I would highly propose (it was once addressed in another post) is to not fix the SSL listener to port 443. Make it configurable.

Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.

Question: Any plans of a Linux Release of Distributor (as it exists for repeater ?)

BTW, You guys really do a great job ! I am really looking forward to see V2.

nolazabal · Post by **nolazabal** » 2006-01-09 15:24

posbis wrote:
Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.

i belive you can configure a not ssl port to what ever you want and then using the regualr viewer (not ssl) to connect and since you plan for a intranet wont be much of a problem not using an ssl connection. i think for this you will have to use a repeater configured with tht ports you want

posbis · Post by **posbis** » 2006-01-10 11:25

nolazabal wrote:
posbis wrote:
Maybe the distributor service is running on a machine (on the INTRANET) where already an IIS or Apache is running on SSL port (443) for internal services but has a lot of free capacity. So I would map the firewall external port 443 to another internal port (e.g. 44343) on this machine (port forwarding with translation). In this case distributor would have to listen on port 44343.
i belive you can configure a not ssl port to what ever you want and then using the regualr viewer (not ssl) to connect and since you plan for a intranet wont be much of a problem not using an ssl connection. i think for this you will have to use a repeater configured with tht ports you want

Yes I understand you

but it is not want I want. I am not planning to use this on the INTRANET. I just want to run the distributor on the INTRANET or in a DMZ (my Home-DMZ).

Customers who need support (my friends

will go to a website of mine where they can start the SC-III client already preconfigured to connect to my distributor (so this goes over public INTERNET).

I on the other side will connect from my office to the distributor in my Home-DMZ and takeover the support session. (So this second connection is going over public INTERNET as well.)

This is why I need SSL and why I would like to port forward 443 to another port on a server in my Home-DMZ where already an Apache is listening on 443. This means that distributor must listen on a different port than 443 for SSL because 443 is already the official HTTPS of my Apache.

Regards,
Oliver

mabj · Post by **mabj** » 2006-03-10 07:40

Posbis.

There is one problem you need to keep in mind when using another port than 443 for your SSL communication.

Some customer might have very restricted rules for outbound traffic in their firewalls that prevents outgoing traffic on ports other then well known port like FTP HTTP HTTPS (SSL).

Also keep in mind that the users that are using a proxy server to access the Internet will not be able to connect to your distributor if you aren't using port 443 for the SSL communication.
Most Proxy servers will not default accepts "tunnelling" on other ports than 443.
However, today there seems to be a general problem with the SCIII to connect through some proxy servers.
(See [topic=6063][/topic])

So if you're looking for an app that just will work all the time for everybody you need to use port 443.

One thing that has been bugging me is that using the SSL distributor that will accept SCIII SSL connections will also automatically accept VNCViewer_SSL connections.

I'm using SC (not SCIII) with the distributor today where the SC communicates goes through a SSL wrapper. In this case we can allow only SC to connect to the distributor over the public SSL port but the VNCViewer can only connect from the internal network. This prevents that user outside our organisation can use our distributor to connect to our customer.

This might be something to consider while developing the SCIII with distributor that it should be optional to prevent VNCViewers to connect through SSL.

Cheers

/M

UltraVNC

on hold

on hold

On Hold

Anything to to do help..

SCIII