A very interesting topic. It is important to understand how GoToMcPc is working before we continue on finding a solution.
Looking at http://www.gotomypc.com/remote_access/images/pdf/GoToMyPC_Overview_White_Paper.pdf I see that there is server called poll.gotomypc.com which is the messenger between two instances.
This is already a candicate for a by pass, as opening the address in a browser comes back with an error on http and an endless connection attempt over https, thus we can expect that a proprietary protocol is spoken here, which is somewhat also reflected in the whitepaper.
This address should be put into a global bypass for everything, as MWG wouldn't be able to scan the proprietary data anyway.
In case it does direct connections to the IP, here it is:
poll.gotomypc.com has address 188.8.131.52
As further indicated in the paper, there is indication that the communication betwenn Communication server and clients is proprietary as well: "The communication server relays an opaque, highly compressed, encrypted stream from client to host."
Reading http://www.gotomypc.com/downloads/pdf/m/GoToMyPC_Corporate_Firewall_Support_Features.pdf, the protocol turns out to be called JEDI ("May the force be with you" ) and is indeed a proprietary TCP/IP based streaming protocol.
Unfortunately, Citrix has not published a list of their communication servers. Thus I can only assume that this would be *.gotomypc.com, which I would exclude from SSL Scanner in case used.
Additionally there is indication that port 8200 is used as well. I would therefore suggest to enable that as port for connect requests in SSL Scanner.
hope that helps,
Citrix does publish a list of IP ranges for their Goto* services:
You can create an IPRange list and tunnel them through SSL.
Create list called something like CitrixIPBlocks with values of:
184.108.40.206/20 Block 1
220.127.116.11/20 Block 2
18.104.22.168/24 Block 3
22.214.171.124/27 Block 4
126.96.36.199/26 Block 5
188.8.131.52/24 Block 6
184.108.40.206/21 Block 7
220.127.116.11/19 Block 8
18.104.22.168/20 Block 9
22.214.171.124/19 Block 10
126.96.36.199/22 Block 11
Then in the Tunneled Hosts rule in SSL scanner change it to something like:
URL.Host is in list SSL Host Tunnel List OR
URL.Destination.IP is in range list CitrixIPBlocks
If you want to bypass authentication for these clients too, to prevent the client from a pop-up, use the same list in an authentication rule to skip authentication.
I have done this before and it seems to work for me.
Hi guys, thanks for the feedback, I'm not using SSL scanner, as a test I put my IP into the global whitelist ruleset with a Stop Cycle action but it still fails, I thought this would bypass everything ?
Only certain users have access to GoToMyPC and this is enforced with an AD group so I can't put it in the Global Whitelist
we have a similar problem with using a Citrix-Go-To product, the GoToWebinar.
Our system is MWG 6.8.7 build 8378.
We do not scan SSL-traffic.
We tried to get contact to Citrix support so they could start a test Webinar where we could try to join.
But Citrix support does not answer to our question. Se we are not able to do further analysing of this problem.on 05.11.10 11:43:30 MEZ
In general, remote desktop utilities such as GoToAssist / Citrix, WebEx, etc use proprietary protocols and mechanisms that break under SSL Scanning. Typically the only thing required to get this working thru MWG6/7 is to make sure that any requested URLs / IPs are bypassing the SSL Scanner / being Tunneled. There are some instances where web applications are in use and it may be possible that those applications do not support authentication and will fail if you are enforcing authentication at the MWG proxy / authentication server. If this is the case you will need to work around it such as outlined in this article for version 6.x:
In the case of MWG 7 you will have to setup similar rules that bypass your authentication ruleset based on URL.Host or similar property.
we still have the problem our users cannot join webinars using Citrix GoToMeeting system.
Our system is MWG 6.8.7 build 8378.
We analysed that the GoToMeeting client which is downloaded cannot authenticate against MWG. A logon mask to put in credentials pops up. After typing correct username and password this mask pops up again and again.
In the end no connection to the webinar meeting is possible,
As a workaround we allowed the IP of the PC where the webinar was opened to connect without authentication. But this cannot be the solution, coz we have several thousand users and we don´t know which user will join a GoToMeeting session next..
The problem using Citrix GoToMeeting is only the failed authentication. Here seems to be a problem with Citrix vs McAfee technology.
How can this be solved?
Is it possible to make an exception from authenticaton for the IP ranges which are published by Citrix? [ http://www.citrixonline.com/iprange ]
In our MWG installation we have a user defined categorie for websites that are exluded from authentication.
But we do not know how to put in here IP ranges.
Thanks in advance for your help.
See this for syntax on 6:
You would add these items to the SSL scanner bypass under Proxies > HTTPS proxy > SSL Scanner bypass, this will allow these ranges to pass without authentication and SSL scanning.
~JonMessage was edited by: jscholte on 7/8/11 10:09:44 AM CDT
thank you very much for your help.
we added the list of IPs in SSL Scanner bypass and with GoToMeeting Connection Wizard [ https://www2.gotomeeting.com/wizard?Portal=www.gotomeeting.com ] we have been able to connect.
Now we wait for the next webinar we can join and will see if everything is running fine.
It seems there are many customers have similar problems, or why is there already a list of IPs avaialbale for download at your ftp server?
But the initial problem of not authentication with Citrix GoToMeeting is not solved with this workaround...is there no chance for McAfee support to get in contact wth Citrix support for analysing the failure?