3 Replies Latest reply on Aug 26, 2013 2:55 AM by Ten Jee

    RTMFP and firewall/NAT traversal options

    Ken Smith (Alanta) Level 1

      I'm in the process of putting together a set of recommendations for folks who want to use our software solution, which uses Flash/RTMFP. Among these, I need to provide them with configuration requirements for their firewall or NAT.

       

      I've read through what seems to be the main thread on this issue (http://forums.adobe.com/thread/583118), in which it's indicated that companies need to open up some 60,000+ outbound UDP ports in order to get RTMFP to work.

       

      I've dealt with enough corporate security folks in my lifetime to know that they're gonna laugh at me if I tell them that they need to open up that many ports to get our software to work. In my experience, an outside vendor is lucky if they can get a typical security guy to grudglingly open up three or four ports. If you have a really compelling reason, maybe he'd be willing to open up a range of 100 ports. But many if not most corporate environments operate with a "deny all" security philosophy, namely, they deny all unknown traffic, and only allow traffic out over specific whitelisted ports. If it really is true that RTMFP requires abandoning that "deny all" philosophy, that effectively renders RTMFP worthless in many (most?) corporate environments.

       

      So I'm just double-checking, because I keep thinking that I must be misunderstanding something. What is Adobe's recommendation for RTMFP in corporate environments? Is it possible, for instance, to configure the RTMFP client to only try a specific set of ports, e.g., 59000-59100? Is it possible to configure the RTMFP server that is handling the traffic to tell the client only to use a specific set of ports? Or any other way to get RTMFP to work without opening up every single outbound UDP port?

       

      I'm aware, of course, that it's possible to fall back to RTMP instead of RTMFP in these situations. But that adds additional latency to the conversation, and increases the amount we have to spend on servers and bandwidth, so I'd prefer to stick with peer-to-peer if at all possible. And lots of other apps (Skype specifically comes to mind) have figured out how to make peer-to-peer connections in all but the very strictest environments: so I'm hoping that there's a way to make RTMFP do the same thing.

       

      Any additional guidance here?

        • 1. Re: RTMFP and firewall/NAT traversal options
          Michael Thornburgh Adobe Employee

          there is no way to control which port an RTMFP client will use. RTMFP clients bind to a random UDP port. and of course if you go through a NAT, then the translated port will be a different and totally random port.

           

          the server exerts no influence over the choice of port.

           

          RTMFP's NAT/firewall traversal techniques make it so that if you allow "outbound UDP" to any port (and allow replies to come back in), you should be able to do P2P in most cases.

           

          some of the tricks "other applications" use wouldn't be appropriate for Flash Player (in particular, relaying/tunneling via other peers, and using well-known ports that are often let through firewalls for their well-known "real" applications, (such as UDP port 53/DNS)).

          • 2. Re: RTMFP and firewall/NAT traversal options
            Ken Smith (Alanta) Level 1

            Thanks, that's what I needed to know.

             

            For what it's worth, I continue to think that it would be worthwhile to allow ActionScript to tell the RTMFP connection object that it should only try to establish a connection over a given range of ports. That way, folks in our position could tell network administrators, "You only need to open up ports x-y", not, "You need to open up every single port."

            • 3. Re: RTMFP and firewall/NAT traversal options
              Ten Jee

              Excuse my ignorance, but isn't this similar to how things like Oracle TNS work? The initial handshake for database connection is (usually) port 1521, after which the session connection is maintian on some very high port number, albeit TCP. I can't imagine there'd be a rule(s) on firewalls for all these high number ports.

               

              Also, check out this link for RTMFP connectivity test - it checks/reports on whether you can access an RTMFP server from wherever you are:

               

              http://cc.rtmfp.net/