TeamViewer writes log files for TeamViewer staff to identify historical actions, technical troubleshooting and bug find in TeamViewer.
This article applies to all TeamViewer users.
In general, these log files are intended for TeamViewer staff and not for end-users. However, the log files are accessible for end-users too.
When opening the log files you may find them overwhelming and confusing as there is a lot of data included. In the interest of transparency and people feeling safe and secure we have established a guide to help end-users read the logfiles on a basic level to identify successful and unsuccessful connection attempts for incoming connections.
Disclaimer
The following descriptions and information given are massively oversimplified and can never reflect how TeamViewer sessions are actually created.
This article intends to provide some basic and limited knowledge that is understandable for everyone. To keep it as simple and as understandable as possible, we decided to use a parable as an example.
What is being described below happens within milliseconds and basically not noticeable for users. The passage in Stage 3 is a massively oversimplified description to follow the plot of the example and does not reflect how the TeamViewer password validation works. TeamViewer does not see or know the password and will never see it. The password is checked locally on the client.
Always remember that logfiles are designed for troubleshooting. Because of this, the amount of time covered by the logfiles is limited. The logfile is 1MB by default. When this reaches the maximum size, this becomes logfile_old and a new logfile is started. (any previous logfile_old is erased when this occurs).
This document cannot cover all cases where an error occurs. Please know that in case something unexpected happens you can´t expect to see these log entries.
Identify a connection
As TeamViewer connections are negotiated through our central servers it is important to note that there is much encryption and authentication that occurs before an incoming connection attempt is successful.
For more information about TeamViewer Sessions please refer to our Security handbook.
📌Note: To be able to read the TeamViewer logfiles completely, special training is required that only TeamViewer staff members on certain positions receive.
Therefore, for people not familiar with analyzing TeamViewer log files, it is easy to think that a session has been established even if it only was a connection attempt when trying to read log files.
After reading this article, you will be able to differentiate between a connection attempt and a successful connection.
Successful Connection vs. Connection attempt
A successful connection is the outcome of a highly secured encryption and authentication process that actually results in one person being able to see the remote device. Depending on the settings on the devices limited or full remote access is possible. All successful connections are listed in the Connections_incoming.txt log that you can find in your TeamViewer folder.
A connection attempt may or may not result in a successful connection. No access to the remote device is established and the person trying to connect has no access to the remote device.
The 5 Stages of a TeamViewer connection
To identify and explain the five stages of an incoming TeamViewer connection, we take an example that helps us to explain and visualize a TeamViewer connection. This example is a setup in which Bob is trying to connect to Sallys computer.
As a second layer of this example, we use a parable of a telephone call that is being setup with the help of a telephone operator that were usual back in the midst of the 20th century.
💡Keep in mind: Each stage of the connection must succeed. A single failure results in the connection being denied by TeamViewer .
Stage 1: Establishing a connection attempt
The first stage in our example of Bob trying to connect to Sally, is comparable with Bob typing Sallys phone number and her telephone is ringing.
We now hit pause and zoom in on what is happening to make Sallys telephone ring at all. Let´s assume there is a telephone operator in the middle receiving Bobs request:
Bob calls the operator: "Hello operator - this is Bob. I´d like to talk to Sally".
Operator: "Yes - please hold".
Operator calls Sally.
Sallys telephone is ringing as the operator calls her.
👉Bob is not talking directly with Sally at this stage. And with this, we have a connection attempt. Below is an example of how this attempt looks like in the log file.
Here you can also see which routers have been used for the connection attempts. The choosen router is selected to guarantee the best possible performance and can differ depending on the time of the day. All routers are in an ISO 27001 certified environment and all connections are always end-to-end encyrpted.
Keep in mind: No connection has been established at this point:
CommandHandlerRouting[2]::CreatePassiveSession(): incoming session via AU-SYD-IBM-R008.teamviewer.com, protocol Tcp
Stage 2: Block and Allowlist check
Sally picks up the phone: "Hello - this is Sally"
Operator: "Hello Sally - this is the operator. I have Bob trying to connect to you. Would you allow that?"
Sally checks her allowlists and replies after she saw Bob on her allowlist: "Yes - Bob is on my allowlist. I am ready to proceed to the next stage of authentication".
👉As Bob has been added to Sallys allowlist sometime in the past, Sally agrees to continue the process of this connection attempt. Still - Bob is not talking directly with Sally at this stage. And with this, we still only have a connection attempt. Below is an example of how this check looks like in the log file. Keep in mind: No connection has been established at this point:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::AuthenticateServer()
👉In case, Bob would not be on Sallys allowlist or would even be on her blocklist, Sally would refuse to talk to Bob at all and the connection attempt would immediately stop. Below is an example of how this refuse looks like in the log file:
CLoginServer::CheckIfConnectionIsAllowed() CLoginServer::CheckIfConnectionIsAllowed: Partner 111111111 (Bob) not whitelisted CLoginServer::runServer: Connection is not allowed
Stage 3: Easy access and Password check
Operator says to Sally: "Please hold" and goes back to Bob.
Operator says: "Hi Bob - what is the password to talk to Sally?"
Bob says: "It is 'Open Sesame' "
Operator says: "Thank you - please hold"
Operator says to Sally: "Hi Sally - Bob says 'Open Sesame' is the password"
🚨 DISCLAIMER: This is not how TeamViewer password works. It is a massively oversimplified description to follow the plot of the example. TeamViewer does not see or know the password and will never see it. The password is checked locally on the client.
In case, Sally confirms the password the Operator connects the two lines together and leaves the connection (=successful handshake). With this, the operator can´t hear Bob or Sally.
👉In the log file the checks for Easy Access and the password looks like this (successful):
Easy Access V1
AuthenticationPublicKey_Passive::Verify: Success
Fixed Password
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using fixed password was successful
In case, Sally says the password is incorrect the process goes back to the start of Stage 3. Bob gets a new chance to give the correct password. After too many unsuccessful atempts, Sally and the operator will refuse the connection attempts and Bob will get blocked for an amount of time.
👉In the log file the checks for Eacy Access and the password looks like this (unsuccessful):
Easy Access V2
LookupPublicKeyV2: Manager {~keyabcd1234} does not have EasyAccess right, reject Authentication
Dynamic Password
AuthenticationPasswordLogin_Passive::RunAuthenticationMethod: authentication using dynamic password was denied
Stage 4: Successful Connection starts
After Bob was able to authenticate successfully via Easy Access or password, the connection starts.
Bob is now talking directly with Sally. And with this, we have a successful connection. Below is an example of how this successful connection looks like in the log file:
CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob CPersistentParticipantManager::AddParticipant: [222222222,-987654321] type=6 name=Sally CPersistentParticipantManager::AddParticipant: [111111111,-123456789] type=3 name=Bob
Stage 5: Connection ends
At any point in time, Sally or Bob can end the connection and the connection is finished and Bob and Sally can´t hear each other any longer. If they want to talk again, they need to start again at Stage 1.
👉Below is an example of how the Session End of a successful connection looks like in the log file:
SessionManagerDesktop::SessionTerminate: removing session with TVSessionID = -123456789
In case Bob was never able to authenticate successfully via Easy Access or password, a complete refuse of their connection attempt follows. There has not been any connection at all.
👉Below is an example of how the Session End of an unsuccessful connection looks like in the log file:
SessionManagerDesktop::SessionTerminate: no session with ID=123456789, aborting logins
💡Hint: The IDs shown in the Logfile for TVSessionID and ID are not the TeamViewer IDs but the ID for the individual session - These cannot be used to identify anyone or any devices nor to connect to anyone.
ID's used in this example
111111111 - Bobs TeamViewer ID
222222222 Sallys TeamViewer ID
123456789 - session ID 1 (= no TeamViewer ID)
987654321 - Session ID 2 (= no TeamViewer ID)