Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense blocking UDP for TeamViewer

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 3 Posters 12.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      markoweb
      last edited by

      For some reason pfSense 2.1.x branch is blocking outgoing/incoming UDP connections for TeamViewer.

      I have the latest TeamViewer 9 version installed on both sides and "Use UDP (recommended)" is ticked under Options -> Advanced -> Advanced networking.
      If there is no pfSense between my side and remote host, then UDP is working fine.
      Any combination of pfSense doesn't allow UDP connections to be created:
          My Side -> Remote side => result
      –-----------------------------------------

      1. pfSense -> pfsense => TCP only
      2. pfSense -> Cisco ASA => TCP only
      3. Cisco ASA -> pfsense => TCP only
      4. Cisco ASA -> Cisco ASA => UDP and TCP working
      5. Linksys home router -> Cisco ASA => UDP and TCP working

      All my pfSense installations are fairly simple. Default install, no packages, couple of port forwardings and that's it.
      My outgoing LAN rules are defined like this:

      Nothing special, only SMTP port is blocked from non e-mail servers. Even without that rule, UDP is still not working. I haven't tried outside of the 2.1.x branch, whether UDP works, all my pfSense installations are in the 2.1.x branch…
      Status -> System Logs -> General and Firewall - don't show any connections being blocked when I'm trying to connect with TeamViewer.

      Can someone help shine some light on this issue?
      How can I diagnose this further?
      How can I try to fix this issue?

      1 Reply Last reply Reply Quote 0
      • K
        kejianshi
        last edited by

        Is UPNP enabled?  If not, try enabling it.

        1 Reply Last reply Reply Quote 0
        • M
          markoweb
          last edited by

          @kejianshi:

          Is UPNP enabled?  If not, try enabling it.

          UPNP was not enabled. I enabled it and allowed both UPNP and NAT-PNP, but still UDP connection could not be established.
          Also, I don't think TeamViewer uses UPNP. Status -> UPNP also showed that no ports were enabled/created at any time during the connection.
          (I turned off my Win7 firewall for testing sake)

          I googled a bit more and it seems that TeamViewer uses UDP hole punching to create a direct connection. In essence both parties at first talk to a proxy server via HTTPS/SSL, after PIN/Code verification the proxy server gives both clients each others IP-s, then both clients start sending UDP packets to each other.
          Because I'm sending UDP packets out to a certain IP and I am getting UDP packets back from the same IP, a firewall should create an automatic pass through rule, but pfSense is blocking this for some reason. I actually saw some blocked UDP packets in the System -> Firewall logs now, from the same IP was connecting to (don't know how I missed this first time round).

          Creating an inbound Firewall rule to allow UDP from all sources to all destinations got rid of the blocked messages in the Firewall log, but TeamViewer still couldn't create an UDP connection. Most likely because the proper NAT mappings have not been created, pfSense isn't forwarding the UDP packets to my machine.

          So the question now becomes, how to enable UDP hole punching in pfSense?

          1 Reply Last reply Reply Quote 0
          • M
            markoweb
            last edited by

            Okay, problem solved :)

            The problem inherintly lies in pfSense rewriting the Source port.
            To disable this feature I followed:
            https://doc.pfsense.org/index.php/Static_Port

            Instead of creating a new rule, I simply edited the existing "Auto created rule for Lan to Wan" and checked Static Port.
            Now I get to have UDP connections with TeamViewer - yei :)

            1 Reply Last reply Reply Quote 0
            • K
              kejianshi
              last edited by

              Wow - Yeah.  Static port is not usually requred for teamviewer.  I'm using teamviewer daily behind pfsense and I only have static port enabled for sip devices.

              Glad its working, though.

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                Yeah, I use TeamViewer out of and into office LANs behind pfSense without doing anything special for it. I am surprised you had trouble. TeamViewer is usually like Skype - it is good at finding its way out from behind NAT…

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • M
                  markoweb
                  last edited by

                  @kejianshi:

                  Wow - Yeah.  Static port is not usually requred for teamviewer.  I'm using teamviewer daily behind pfsense and I only have static port enabled for sip devices.

                  Glad its working, though.

                  You are right that static port is not usually required for TeamViewer. TeamViewer can work in such a case, but will simply revert to TCP connection.
                  The problem with TCP is that file transfers are ridiculously slow - hard limited to only 120 kb/s.
                  With UDP, file transfers get pretty much maximum speed. I guess TCP traffic has to go through TeamViewer proxy servers, that's why it is hard limited.
                  I suppose, regular remote control will also get a speed boost with UDP…

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.