I have a problem with the MWG7 SSL scanner and teamviewer software.
Two weeks ago the teamviewer software has worked over the MWG7 proxy without problems. Now it is not working anymore.
To solve the problem I have made a connection tracing. Teamviewer first connects with *.teamviewer.com hosts over port 443. This works, because I have put *.teamviewer.com on the SSL tunneled URL list.
After the successfull port 443 connections teamviewer wants to connect to a host with an IP address. Because the IP address is not on the SSL tunneled URL list and the SSL protocol is proprietary, the MWG7 can not handle the SSL protocol and shows the error message 'SSL routinesSL23_GET_CLIENT_HELLO:unknown protocol / HTTP/1.0 500 handshakefailed'. I have put the IP address on the SSL tunneled URL list. Ervery time the teamviewer software is started the software uses a different IP address which is not on the SSL tunneled URL list. The MWG7 closes the connection with a ssl error message 500.
I have asked the teamviewer support for a list with all teamviewer IP addresses. They have answered that this is not possible, because the IP addresses change often and there are new IP addresses from time time.
On the teamviewer hompage they say.
Which ports are used by TeamViewer?
In general, TeamViewer will always work if surfing on the Internet is possible. Hence, no firewall configuration is required. As an alternative to port 80 HTTP, port 443 HTTPs is also being checked. In addition, it is also possible to open only port 5938 TCP on the outgoing side. Data traffic should then be able to pass through on this port without any problems.
I have disabled the SSL scanner. Without the SSL scanner the teamviewer software is working.
How can I configure the SSL scanner so that it won't scan the teamviewer IP connections, but all other SSL traffic?
I know there are McAfee maintained lists (IP ranges) for Citrix, JoinMe WebEx. Will there be a list for teamviewer in the future?
I don't know teamviewer, but many client applications have an option to not resolve hostnames themselves but leave it up to the proxy server. Those applications can be tuned to not request IP-based URLs.
Well, some applications behave nasty and demand those IP-based URLs. In these cases you may use a rule based on user-agent. Not perfect, as smart users know how to trick user-agent strings.
the McAfee maintained lists are build on what the software vendor provides. It would be too much work to manually craft those lists and keep it up to date, especially when there is no way to verify that all IP addresses are included. So its unlikely that we can provide such a list.
Can you provide some more information on what version of TeamViewer you run, and when the problems occur? I just took a Windows 7 host which only is allowed to talk to MWG on Port 9090, went to teamviewer.com and launched "Run Full Version". I chose "Run Only/Personal use". It took a few seconds, but it successfully connected, the TeamViewer software showed a green "Connected (Secure Connection)" message at the bottom.
To validate I also participated a meeting from from the restricted system to another workstation (not behind MWG) and the screen sharing went fine.
What I could see was that there was a single HTTPS attempt by the team viewer software calling ping.teamviewer.com. This was declined by MWG due to handshake failure. It seems TeamViewer then started speaking HTTP, obviously via a service/protocol called DynGate (or similar). Requests such as "GET /din" and "GET /dout" went through the proxy. The access.log shows:
[19/Aug/2013:09:35:39 +0200] "" 10.150.64.132 200 "GET http://220.127.116.11/dout.aspx?s=39424760&p=10000053&client=DynGate&data=ETBrACcAAAAAAAAADQEAAAIAAAAY... HTTP/1.1" "Remote Access" "Minimal Risk" "" 182 411 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
[19/Aug/2013:09:35:39 +0200] "" 10.150.64.132 200 "GET http://18.104.22.168/din.aspx?s=39424760&id=220980192&client=DynGate&p=10000045 HTTP/1.1" "Remote Access" "Minimal Risk" "application/octet-stream" 331 258 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
[19/Aug/2013:09:35:39 +0200] "" 10.150.64.132 200 "GET http://22.214.171.124/dout.aspx?s=39424760&p=10000054&client=DynGate&data=ETBrADcAAAAAAAAAEQEAAAIAAAAY... HTTP/1.1" "Remote Access" "Minimal Risk" "" 182 435 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
[19/Aug/2013:09:35:39 +0200] "" 10.150.64.132 200 "GET http://126.96.36.199/din.aspx?s=39424760&id=220980192&client=DynGate&p=10000046 HTTP/1.1" "Remote Access" "Minimal Risk" "application/octet-stream" 1472 258 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
[19/Aug/2013:09:35:40 +0200] "" 10.150.64.132 200 "GET http://188.8.131.52/dout.aspx?s=39424760&p=10000055&client=DynGate&data=ETBrACoAAAAAAAAAEgEAAAIAAAAY... HTTP/1.1" "Remote Access" "Minimal Risk" "" 182 415 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
[19/Aug/2013:09:35:40 +0200] "" 10.150.64.132 200 "GET http://184.108.40.206/din.aspx?s=39424760&id=220980192&client=DynGate&p=10000047 HTTP/1.1" "Remote Access" "Minimal Risk" "application/octet-stream" 604 258 "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)" "" "0" ""
It looks that also the TeamViewer IPs are categorized as "Remote Access". I also noticed that the GET Requests and also the single CONNECT request I saw are showing the User-Agent string "Mozilla/4.0 (compatible; MSIE 6.0; DynGate)", so probably there is a chance to capture such requests by utilizing URL Filter and/or the user-agent string.
Are you running MWG in explicit proxy mode? I assume in transparent mode we won't have a chance to look into the User-Agent since there is no connect request unless MWG has called SSL Scanner to decrypt the session. In this case it would still be interesting if there is a way to get TeamViewer working as shown above by using HTTP. Since it reports that the channel is secure I assume it performs end-to-end through HTTP, so it should be acceptable to use HTTP. The TeamViewer support might be helpful here, because only they know how their tool is supposed to work.
Because I cannot repliace the problem I cannot provide more details, but maybe you get some idea to start.
After a quick look, Teamviewer behaves as any other P2P protocol. It will try native connections first and in case it can't succeed it will fall back to using web traffic. For me it tried HTTPS which ran into an error, then it moved to http, which worked.
A quick wireshark shows that it uses a specific useragent (at least on my Mac):
User-Agent: TeamViewer/1 CFNetwork/596.4.3 Darwin/12.4.0 (x86_64) (MacBookPro10%2C2)
I would agree that a list for Teamviewer would be important. I would love to see some policy that could grant individual app control access - like "outbound only".
Thank you for your replies. The given answers helped me to solve the problem.
My first attempt to solve the problem was to get all teamviewer IP addresses for the SSL exception.
A colleague has written a php script which collects all teamviewer server IP addresses.
The php script asks the internet DNS for the IP addresses from "server?.teamviewer.com" (? goes from 1 to 100000) and fills a file "teamviewer-ips.txt".
The beginning of the file teamviewer-ips.txt looks like as follows:
The php script runs every day and creates an actual list of the teamviewer IP addresses.
On the MWG7 I have configured a subscribed list "Teamviewer IP List" which gets the list from a ftp server and makes a content update every day.
right mouse button "Add"
Windows "Add List" opens
Name: "Teamviewer IP List" Type: IP
x List Content is managed remotely
x Customer Maintained List: "Setup"
Window "Setup" opens
URL to download: ftp://.....
Username / Password
List Content Update:
x Daily at 22:00 o'clock
In the policy rule set "SSL Scanner" / "Handle CONNECT Call" I have made a new rule which skips the SSL scanner if a teamviewer IP is invoked. For this rule I have used the subscribed list "Teamviewer IP List".
My second attempt to solve the problem was to use the given hints in the answers to my question.
I have got a test client in the customer network to test the teamviewer software. In the teamviewer software you can configure proxy settings
1. Automatically detect settings (recommended)
2. Use manual proxy
With the first option teamviewer did not work. It did work with manual configured proxy IP and port.
The customer uses a configuration script (pac file). I think that teamviewer can not detect the proxy settings out of the configuration script.
After reading your comments to my problem I have changed the rule set "SSL Scanner". I have deleted the SSL exception for teamviewer.com and the "Teamviewer IP List". Without the SSL exception the teamviewer software works. But only with a manual configured proxy in the teamviewer software.
to make this less static I added this rule to the Global Whitelist Rule Set:
Name: Allow Teamviewer Server-IPs
URL.HostIsIP equals true AND
DNS.Lookup.Reverse (URL.Destination.IP) contains at least one match regex(^server[^\.]*.teamviewer.com)
Action: Stop Cycle