SC unable to connect to listening viewer??

[amn0270]

I am having a strange problem. I was looking for easy remote access ability for my clients so I setup SC and put it on my website so people can get to it and launch it if I need them to. I opened port 5500 on my router. I then tested it by having my friend activate SC from his house via my website and it worked. A couple of days later it just stopped working. I checked and my router is still set right. I even checked to see if the port was somehow being blocked from elsewhere such as my ISP by using canyouseeme.com port checker tool that checks for open ports and it seems that the port is still open. If I run the viewer in listen mode and have that site check port 5500 to see if its open the viewer actually reacts to the port check and generates a "The connection failed - incorrect protocol version" error so I know the the viewer detected an incoming request on that port. But for some reason the SC will only connect to machines running the listening viewer if they are within my network. Cannot imagine what is going on outside my router being that the open port is being seen from the Internet. Any ideas?

Thanks in advance,
Adam

[Sergio]

Version of the viewer ? Just shooting in the dark ...

[amn0270]

Its RC19.5 but as I said it works when connecting from within the network. Just won't when someone tries from out on the Internet.

[Sergio]

Read this thread: [post=7417][/post]

Current SC is pre RC195.

The plugin included was a special compilation. I removed all registry rederences in the plugin and replaced it by fix name
and winvnc runpath.

Use viewer RC193 or RC194.
As plugin you can use the same plugin as for RC18 or just extract the plugin (using 7zip) out of the SC exe.

I had a similar problem ... Just a guess, but maybe you have UltraVNC RC19.5 installed on the internal network, and SC is not running SC winvnc, BUT the RC19.5 winvnc ... thats why works from the internal network, and not from the internet.

On the other hand, if you use a plugin, be sure that the rc4.key and MSRC4Plugin.dsm included on your SC is exactly the same that you are using with the viewer. There are some reports that the SC generation script had errors, and included always the same rc4.key, and not the customized one.

HTH

[Guest]

Its RC19.5 but as I said it works when connecting from within the network. Just won't when someone tries from out on the Internet.

Hope someone else can help with this. I am still having this problem only now it will not connect either within the network or from the Internet. I've tried with both a Linksys router and a Belkin. Seemed to work within the network with the Linksys connected but wouldn't work either way with the Belkin. Now after hooking the Linksys back up it won't work either way so I guess the routers are not the caus. With either router the port that I have mapped to the listening viewer is open as confirmed by an external open port test. Does anyone have any other ideas???

[amn0270]

I just determined something else. I tested it by connecting using the regular WInVNC Server of UltraVNC rather then the SC and what I get is the message that it failed to connect to port. So this concludes that SC itself has nothing to do with the problem.
Something is preventing the server from connecting to the listening viewer when the connection to the viewer is requested via an external IP. If I do it from an internal IP it works. However like I said in the above post, if I run a port test from the Internet it triggers an error dialog box from the listening viewer regarding DSM plugin error which is irrelevant to the issue but put proves that the viewer is definitely able to receive incoming requests from the port its listening on. So all I can figure is that the server is not able to make to request, not that the viewer is not able to receive it. The question is why? My firewall can't be the issue or the port would be blocked altogether and the port test would have failed. At least that how I see it.

[ipsec]

if I run a port test from the Internet it triggers an error dialog box from the listening viewer regarding DSM plugin error which is irrelevant to the issue but put proves that the viewer is definitely able to receive incoming requests from the port its listening on. So all I can figure is that the server is not able to make to request, not that the viewer is not able to receive it. The question is why? My firewall can't be the issue or the port would be blocked altogether and the port test would have failed. At least that how I see it.

Your assumption is probably right on. If you do a internet port scan - and you hit the port you are using. The error for the listener comes up if you are using DSM. Meaning someone scanned or tried to connect to you but since you werent speaking the same language it failed.

Your question of why..... My thoughts would be who it is you are having run SC (or server with the add new client)... Possibly they are not allowing the port you have configured out.

Now you said you did an internet port scan - did you scan it from a website or a different computer connected independantly to the internet? If it was an independant of your home network then you could of course try this... Which I may assume you have.. but until I read it I dont know...

IF the person you are having connect to you is behind a corporate firewall or behind a similar type device (surf control / proxy) you may only be able to specify well known ports such as 80 or 443 for Web or SSL. I have no idea what port you are running it on but of course I dont expect you to jump into that area right now.

Lets see the response of -
Do you have an independant connection of your home network? (Direct or otherwise connected with no Proxy/Firewall)
Are you using DSM?
Is the person you are trying to have run SC behind corporate firewall / hardeware firewall?

Then we may be able to go forward from here... but I agree with you completely.. the port scan giving you the error means your ports are forwarding correctly.

[amn0270]

Do you have an independant connection of your home network? (Direct or otherwise connected with no Proxy/Firewall)
Are you using DSM?
Is the person you are trying to have run SC behind corporate firewall / hardeware firewall?

Then we may be able to go forward from here... but I agree with you completely.. the port scan giving you the error means your ports are forwarding correctly.

Well the problem seems to have solved itself mostly but let me clarify for you anyway. If you mean is the listening viewer running on a separate network from the server the answer is yes and no. I have 3 machines on my network all sharing a DSL connection via a Belkin router. One machine I ran the listening viewer, on port 5100. Port forwarding is set on the router for that port number. On another machine I ran the server. Connecting via external IP it fails. Using an internal IP it works. Ran this test with a few different people who were actually out on the Internet using my SC configured with the external IP and it still would not connect. Many of them are behing some sort of firewall either hardware or software based. If I run the test within my network with both server and viewer I still cannot connect to it via the external IP but it works with the internal. Now just yesterday I tried it again with another person out on the Internet and now it worked. Not sure why as I have not changed anything. BTW that person was behind a Linksys router firewall. I thought the benefit to having the server connect to listener instead of the other way around was that any firewall running on the server side did not need to be configured and wouldn't interfere. Maybe I was mistaken. Seems to be unpredictable at this point but I will keep watching it. Oh and at this point I am not using the DSM. Once I got it all working smoothly I was going to add that in. Thanks for your input

[Rudi De Vos]

Routers does not require configuration..(port forwarding)
But if the person running the server has a firewall running
on his PC, he still has to accept the outgoing connection.

The normal security behaviour is a popup that ask if the application can access the internet...
But i'm sure some sysadmins block everything that has not been approved by them.

[ipsec]

I will try to help out with what you posted

Port forwarding is set on the router for that port number. On another machine I ran the server. Connecting via external IP it fails. Using an internal IP it works.

External IP connections VIA SC and Viewer are DEPENDANT on the router. My equipment seems to work by using my dyndns.org ip address. So your router may not want to connect to itself.

Ran this test with a few different people who were actually out on the Internet using my SC configured with the external IP and it still would not connect. Many of them are behing some sort of firewall either hardware or software based.

Hardware based firewalls are more stringent. This is what I believe the devs mean by "Corporate" firewall... However you can get around those issues by using well known and often used ports. Software based firewalls should ASK the user if you want to do something therefore it should work

If I run the test within my network with both server and viewer I still cannot connect to it via the external IP but it works with the internal.

IF you can do anything on your internal network but can not outside the main causes will be - Router (ports not properly forwarded) or Firewall (Not allowing anything through but local subnet)

Now just yesterday I tried it again with another person out on the Internet and now it worked. Not sure why as I have not changed anything. BTW that person was behind a Linksys router firewall.

Have you removed any of the port forwarding configurations.. I know you said you didnt do anything but somtimes removal is just as good as addition It was in my case for SC to work.

I thought the benefit to having the server connect to listener instead of the other way around was that any firewall running on the server side did not need to be configured and wouldn't interfere. Maybe I was mistaken. Seems to be unpredictable at this point but I will keep watching it. Oh and at this point I am not using the DSM. Once I got it all working smoothly I was going to add that in.

The benefit is that you have them initiate the connection therefore eliminating the need for them to do portforwarding. They do have to allow the app to go out and connect on their software firewall. HOWEVER - if you have a hardware firewall on (Corporate) scenario it may need some tweaking in order for it to work.

I would have to say after you figure out your networking issue - its not unpredictable.. If it works locally then making it work over the Inet only adds 2 peices... Router / Firewall... and those are the most likely root causes.

Thanks for your input

your welcome