1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

TeamViewer classification rule in Tomato QoS

Discussion in 'Tomato Firmware' started by Cayennr, Jul 4, 2013.

  1. Cayennr

    Cayennr Reformed Router Member


    I’m using Linksys E2000 running on Tomato Firmware v1.28.7502 MIPSR2Toastman-RT K26 Std. I have set up the inbound and outbound values and I haven’t changed any of default classification rules since I don’t fully understand that stuff. For now, everything seems to be working, but I need help adding TeamViewer under the “Remote” class, because now goes through “P2P/Bulk.”


    It seems like the port 5938 TeamViewer uses is already in one of the “Remote” rules, but for some reason TeamViewer still goes under “P2P/Bulk.”


    By Googling I came to understanding that TeamViewer is a pain to setup, but I wondered if someone knows a fix for this.

    (Please excuse me if I sound silly, because I am a complete noob when it comes to this stuff, plus I’m not a native English speaker.)

    Thank you.
  2. rs232

    rs232 Network Guru Member

    afaik the latest releases of teamviewer use UDP by default and not TCP. Worth a try...


    So I would remove the teamviewer port from where it is and create a new rule for UDP 5938 src/dst. With the above settings you should be good to go.
  3. Cayennr

    Cayennr Reformed Router Member

    @rs232 Thank you for your reply. What you suggested looks like it’s working, but with TCP/UDP and port 5938, not only UDP.

    Now, the direct traffic of the PC I’m connected to goes through Crawl, like shown here:

    The “D Port,” 3603 in the above pic, seems like it’s changing with every new TeamViewer connection.
  4. rs232

    rs232 Network Guru Member

  5. Cayennr

    Cayennr Reformed Router Member

    No, I’m not using something like that. I tried connecting again and now it’s showing that it uses port 3383, another time I connect it shows 1790, then 1818, then 49761. It’s different every time.

    I attached a screenshot of the classification rules. The TeamViewer port is under 11 together with the RDP port.

    Edit: Do you suggest to add 80 and 443 to the same rule where 5938 is now? Or a new TCP/UDP rule with these ports 80,443,5938?

    Attached Files:

  6. rs232

    rs232 Network Guru Member

    Can you keep an eye on the amount of data transferred for these "random" ports? it it's only few bytes one off I wouldn't waste too much time on it, different if remote admin and file transfer use them instead. Leave a session open and see where data is counted (within teamviewer or elsewhere).

    In my LAN I set teamviewer not to use port 80 (as per image above) and I do use different rules for remote admin and web traffic. It seems to be working fine so yes I would recommend it

    If I can give you a little tip not related to this issue: try to remove the protocols/ports you don't use from the classification page: the shorted the better as long as you can classify everything you need. Also double check any Layer7 detection you might be using as filters are far from being precise and false positive classifications are common.

    P.S. what have you set under: QoS/Basic settings/"No Ingress QOS for UDP"?
  7. Cayennr

    Cayennr Reformed Router Member

    Thank you for the tip. I might remove some of the messenger and VOIP/games protocols I don’t use, I was just afraid not to break something and I didn’t want to touch there.

    I tried with these settings: TCP/UDP src/dst port 5938, and “don’t use incoming port 80” in TeamViewer checked, as you suggested in your first post of this thread. This is what happens:


    Two connections to two different computers on a two different networks using different ports again. On the first connection using port 2014 you can see I transferred a 4.5 MB file and all went through class “Crawl.” I have added a screenshot of the pie graphs too as an attachment. The “Destination” is the computers public IP addresses.

    In the meantime this happens under “Remote”:


    “No Ingress QOS for UDP” is unchecked, as set by default.

    Attached Files:

  8. rs232

    rs232 Network Guru Member

    did you install the VPN diver by any chance? You'll find the option above the "use UDP (recommended)", if so try to remove and see how it behaves.
  9. Cayennr

    Cayennr Reformed Router Member

    No, I don’t have the VPN driver installed.
    Oh, I thought this would be an easy fix, I didn’t thought it would be this complicated.
  10. Toastman

    Toastman Super Moderator Staff Member Member

    I'm not at home to try anything, so just dropping in my thoughts. If Teamviewer is opening random ports I would suspect they may be carrying the data and the other ports may have been used purely to set up the link, which is often more normal. To check this, what I would do is to disable QOS and then set up a teamviewer session. Then examine each connection with "QOS - VIEW DETAILS" to see which ports are actually carrying the data, and how much. You could then set a range of ports to cover same - there may be port range info used by Teamviewer somewhere on the web. Note that it isn't usually desirable to open large port ranges because of the likelihood that some P2P app will exploit them, this probably won't be a big problem for you though.
  11. rs232

    rs232 Network Guru Member

    Perhaps it's easy and I'm not able to help myself :)
    I assume you have the full version of teamviewer (no remote admin utility only) and you're running the latest version?
    Can you try to remote admin only for a bit and see where the traffic goes? My guess is that RA goes via the 5938 where file transfer opens another connection. If that's the case this problem is minimised as file transfer is not interactive and you could simply ignore this.
    If all the traffic goes via this random port instead... it different and looks like a problem. I need to double check this myself on my system tonight when I get back home...

    In the meantime you can try posting a question on their forum:

    Sorry if I can't help you in other ways for the time being... does anybody else have better ideas?
  12. Cayennr

    Cayennr Reformed Router Member

    @Toastman I’m not fully sure what you meant by examining each connection, but I tried to screenshot something. I attached the screenshots to this post. The computer I’m connected to is now on port 2095. As you can see on the “Transfer.png” image “Bytes In” shows about 4.5 MB. Sorry if this is not what you meant.

    @rs232 Thank you for your help. Nonetheless, it might be something different on TeamViewer’s side as Toastman mentioned… Yes, I have the latest and full version of TeamViewer. Even if I just remote admin as you suggest, the traffic still goes through Crawl class. If you find out something, please update here. :)

    Attached Files:

  13. koitsu

    koitsu Network Guru Member

    It looks to me like the nature of this software (TeamViewer) is that it uses multiple TCP or UDP sessions -- one is a connection that acts as a "centralised control port" (that's the one you see to TCP destination port 5938), and another via UDP to a completely/dynamically allocated port number.

    There is basically no way possible, out side of very complex and very CPU intensive layer 7 filtering models, for a router to correlate the latter with a "TeamViewer" class for QoS or bandwidth control. L7 introduces extremely complex problems/issues and is very very CPU intensive (many here on the forum have complained about speeds when using it, and it's understandable). L7 means the bytes of every single packet going through the router have to be examined by the CPU and matched against a pattern/sequence of bytes and ""hope"" that the patterns/matches are precise enough to only match certain kinds of traffic.

    It is possible for the client system (meaning in those screenshots) to correlate what's what based on process name (e.g. teamviewer.exe) since a single process would be associated with all those ports at the kernel level. But this is not possible to correlate at the router level. So if you wanted to QoS or bandwidth-limit on the client ( level, you could definitely do that with ease -- this is not related to Tomato, of course.

    I'm going to make this real simple, and I will state up front I am trying very hard to stick with the limitations you've presented/the need to use what you use, but it really isn't feasible if you ask me. So I ask: what exactly are you using this software for, and why are you using this software? From what I can determine from their website, it's remote assistance/remote PC control software. Why don't you use TightVNC? With TighVNC, everything goes across a single TCP port. TightVNC also has file transfer capability (it's new-ish as of 2.x but it's there).

    It is possible to connect to machines behind NAT on TightVNC as well (I do so with my mother when she needs help with her PC -- I'm behind a router (NAT) and she's also behind one. VNC lets you do what's called a "reverse TCP connection" where the *server* (my mum) actually initiates a TCP connection to the *client* (me), because on the client side I have familiarity with what TCP port numbers to forward to make that work (a lot easier than explaining to her how to set up port forwards in her weird AT&T-proprietary router).

    Otherwise if you want a "full remote control" (vs. remote assistance) software and you're using Windows, I really must stress the importance of Remote Desktop / Microsoft Terminal Services. And a single TCP port too.
  14. Cayennr

    Cayennr Reformed Router Member

    @koitsu Hi, thanks for your reply. I’m using TeamViewer mainly because it’s free for personal use and offers easy remote access from and to any PC running on OS X or Windows platform (on the plus side they have an iOS app). The Internet connection we have here uses dynamic IP addresses, so with TeamViewer ID (a unique 9-digit number each computer gets) I can easily connect to any device running the same software without the need to use services like No-IP to announce the public IP addresses of the PCs.

    I’m mostly using it for helping my family members with their computers. Plus, my dad uses this software to connect from work to his home PC and the other way around, mainly to transfer files because he doesn’t believe that cloud services like Dropbox are reliable (what can you do). He’s familiar with it, so I believe he wouldn’t want to learn how to use another, new, software.

    If I can’t make it work I’ll just leave it as it is, it’s not a big deal, really. I was configuring my QoS settings so I thought I’ll make remote connections go through class “Remote,” as they should, to complete my configuration, but at the end of the day I can just let it go. I didn’t thought it would be this complicated, I thought I just need to add/remove some ports from the classification rules, but it turned out a bit more complicated than that.
  15. koitsu

    koitsu Network Guru Member

    Yeah, I'm sorry to tell you that it's probably not going to happen. I say "probably" because I'm not 100% convinced that what you're correlating is correct. Why I say that: this site (thanks rs232):


    Doesn't state anything about a dynamic UDP port being allocated, which brings into question your claims here in the thread, but could also be TeamViewer's documentation being wrong. A lot of the time (in my experience) the user turns out to be wrong/misunderstanding something. They could also be doing something like using UPnP to dynamically allocate a port on the WAN interface which then gets forwarded to your PC (hard to say, I do not know), but I have no idea why they'd use UDP for that (it makes things even more difficult).

    The only way to truly find out what ports/etc. this program is using actively is to look on the client ( Windows offers many ways of doing this (netstat -a -b -n is usually the easiest). There are other programs that make this easier too, like TCPView from SysInternals/Microsoft. If you use TCPView, please turn off Options -> Resolve Addresses before providing a screenshot. And if you hide/obfuscate any of the information shown, it makes it very difficult for people helping you to help, so please don't do that.
  16. Cayennr

    Cayennr Reformed Router Member

    Thank you for the TCPView software. I think it helped me resolve my issue. I have created a new class rule: TCP src/dsc with port 5938, and in TeamViewer I have unchecked “Use UDP” and checked “Don’t use incoming port 80.” Now it seems that all the traffic goes through TeamViewer’s servers and the file transfers are slower because, I assume, I’m not directly connected to the remote PC (because in View Graphs in QoS I don’t see the remote PC public IP address like on the previous screenshots I posted here, now I’m seeing only TeamViewer’s servers which work on 5938).

    Sorry again for all the confusion, I’m very new to this. Thanks to everybody who helped. It’s now working as it should, except for the slower file transfer speeds, but meh, nothing is perfect.
  17. jerrm

    jerrm Network Guru Member

    The docs are obviously wrong, they don't mention UDP at all (which they must use, otherwise no need for a GUI option to disable). The post is probably just listing the minimum ports.

    Most of these apps use UDP hole punching, but they may try UPnP first if available. I've seen several of these P2P type apps only use UDP, with or without UPnP. I guess if they already have all the plumbing for UDP connections they just stick with it. Have no clue what Teamviewer does with UPnP, if anything.

    If the app doesn't self-limit the ports it uses, QOS classification without L7 is damn near impossible, and not simple even with L7.

    Easiest approach if the individual PCs themselves can be somewhat trusted is create a match rule for UDP from the PC(s) that will give reasonable throughput, without risking some rogue app or malware on the PC monopolizing the bandwidth.
    koitsu likes this.
  18. phlibby

    phlibby Reformed Router Member

    I just bought a business license for Teamviewer. When I asked them if they could give me the info I would need to set it up in my QoS, they replied with this:
    From: TeamViewer Team [mailto:support@teamviewer.com]
    Sent: Thursday, May 28, 2015 4:21 AM
    To: pintackccs@gmail.com
    Subject: [#1931139]: About my QoS System

    Dear Pat,

    thank you for contacting us.

    TeamViewer should only use ports 80, 443 and 5938. Port 5938 is the main port which TeamViewer uses, 443 and 80 are just a fallback.

    If you have any further questions about TeamViewer, please feel free to contact us again.

    Best regards,

    Benjamin Strohmeyer
    -Support Technician-

    TeamViewer GmbH * Jahnstr. 30 * 73037 Göppingen * Deutschland
    Handelsregister Ulm HRB 534075 * Geschäftsführer: Andreas König, Stephan Kniewasser

    Tel. +49 (0) 7161 60692 50 * Fax +49 (0) 7161 60692 79 * E-Mail support@teamviewer.com
    Now I am just getting around to sorting this out myself but thought I would step right in and give you any info I find out while setting mine up. I can contact Teamviewer support team and keep asking questions until we get enough information so our kind teachers here may be better able to help us with this.
    I personally don't have a problem with the remote control part of it. Where I run into problems is when I use the file transfer feature. It transfers data very slow being classed as P2P or Crawl and I have to disable QoS temporarily to get the data to move then re-enable it again.

    Woops! Just noticed this was being discussed back in July of 2013. I sure do have a lot to learn.

    Still Learning QoS,
    Last edited: Jul 29, 2015

Share This Page