I posted the following message to the FLASHMEDIA mailing list about a month ago about how to use a server I run in my garage http://cc.rtmfp.net to test NAT/firewall properties:

IF the connection to cc.rtmfp.net has the same properties as the connection to/from the peer, then the results can be used to make a good guess as to whether or not a peer-to-peer connection can be formed. The fact that the connection in some cases does NOT have the same properties is why the results can't be relied upon completely. (As an example, two peers in the same organization behind the same firewall have different properties between each other than they each have to cc.rtmfp.net)

In order to guess, one needs to know that there are different types of NAT behavior. (I'll use the older common terminology below, rather than the new recommended terminology, as most people know the older terminology better):

Some reuse the same address and port when talking to different peers
("cone") and some pick a new address and port ("multiple IP address,
symmetric") or the same address but new port ("single IP address, symmetric"). There is also different filtering behavior of NATs and firewalls. (Note that a firewall may filter and not be a NAT, or a NAT can also act as a firewall and have filtering). The typical kinds of filtering behavior are none (for a cone NAT we would call that "full cone"), restrict to only talking to addresses we have talked to before ("address-restricted"), and restrict to only talking to addresses AND port numbers we have talked to before ("address- and port-restricted").
There are also firewalls that block UDP entirely.

Unfortunately, there are also even more complicated NAT and firewall behaviors that aren't easily characterized. For instance, some act as a symmetric NAT that preserves port numbers at first, then when they run out of resources they switch to being a cone NAT. Some act as one type of NAT for the first client that connects to a server, then a different type if a second client behind the NAT tries to connect to the same server. So this is another case where a simple analysis, like the one performed by cc.rtmfp.net, can fail to properly predict what will happen for the peer-to-peer connection.

But, if the connection to cc.rtmfp.net has the same properties AND the NAT or firewall has predictable behavior, here's what the results mean:

At the top, a successful RTMFP connection will result in "Analysis Complete". If you don't get that, UDP is probably blocked. (Or the cc.rtmfp.net RTMFP server has a problem... it runs on a machine in my garage, with no redundancy)

The for each yes/no answer, there's the following meaning:

"Knows public IP address of self" means that the Flash Player's idea of its local addresses has one address that matches the one that cc.rtmfp.net saw when the connection came in. If that is the case, there's no address translation.

"Public UDP port number same as local UDP port number" means that the Flash Player's idea of which UDP port number it is using matches what cc.rtmfp.net saw when the connection came in. If that is the case, there's no port translation. So if this and the above are "yes", then there's probably no NAT of any kind (but there still might be a firewall)

"Can receive from same IP address, same UDP port number" is always true, because if you couldn't do this you couldn't establish the initial connection.

"Can receive from same IP address, different UDP port number" tells you whether or not your firewall is "port restricted", requiring an outbound connection to the same address AND port number before inbound traffic is permitted from that address and port number, even after traffic was sent to the same address but different port number previously.

"Can receive from different IP address, different UDP port number" tells you whether or not your firewall is "address restricted", requiring an outbound connection to be made to a new IP address before inbound traffic is permitted from that IP address.

"Can send to different IP address after server introduction" should always be true if the initial connection can be made because, unless there is very strange firewall behavior, this is just like opening a new RTMFP connection initially. If this fails then either there's a problem with how the player received or treated the introduction request, or the firewall is totally unpredictable.

"Source IP address is preserved from original connection" means that either you have a cone NAT, or a symmetric NAT with only one IP address, or a symmetric NAT with multiple IP addresses *but* the same address happened to be used this time. If repeated tests cause this to change between yes and no, then you have a symmetric NAT with multiple IP addresses, and sometimes you happen to use the same address.

"Source UDP port number is preserved from original connection" means that you have a cone NAT. If this is "no", then you have a symmetric NAT.

Now, how does this tell you what will and won't work?

Symmetric NATs break peer-to-peer connectivity in some cases. Flash Player can work with almost all cone NAT configurations (though with some caveats if there are multiple layers of NAT and/or lack of "hairpinning" support), and many firewall configurations, but symmetric NAT in combination with certain firewall or NAT cases at the other end blocks the ability to establish a peer-to-peer connection.

If one end is a symmetric NAT with a single IP address, then connections to peers behind other symmetric NATs or behind port-restricted cone NATs (or port-restricted firewalls) are impossible.

If one end is a symmetric NAT with multiple IP addresses, then connections to peers behind other symmetric NATs or behind address-restricted (and likely port-restricted) cone NATs (or address-restricted or port-restricted firewalls) are impossible.

This is because no matter what the Flash Player tries to do to "punch a hole" through the restricted cone NAT or restricted firewall in order to let the other peer through, the other end keeps moving to a new address and/or port number that doesn't match up, so the hole that was created is no longer applicable.

The best choice is to allow UDP traffic through and to use a NAT and/or firewall device that complies with the NAT implementation recommendations of the IETF BEHAVE working group. Alternatively, an organization may choose to use the TURN proxy support in the player to send traffic to a proxy in a DMZ that can comply with those recommendations.

Application developers may also want to create fallbacks to client-server RTMP and/or RTMPT in order to cover the cases where a firewall or NAT blocks a direct peer-to-peer connection. It depends on whether you want your application to always work, or you want to never have to relay media through your server.

Matthew Kaufman