The Challenges of Network Connectivity in Online Gaming

A Firebind White Paper

Its hard to think of anything in the last decade that has had the kind of impact on our lives like the Internet has. It was 30 years ago that Apple spawned the home computing revolution, but back then the only connectivity to anything outside of the home was over a 300 or 1200 baud modem, and it was to a closed community system called a BBS (online bulletin board system.) Fast forward a decade to the 1990s and the Internet finally started coming to the masses with the launch of Netscape in 1994. Modem technology had advanced and speeds of 28.8 Kbps were becoming common, but Internet access for virtually all consumers was still via that 28.8 dial-up connection, at least on a good day when you connected on the first try. At the end of the millennium broadband cable modem technology and DSL connectivity started to take hold, allowing applications such as online gaming, streaming video, and many others to start to thrive, something that simply wasnt ever going to be possible over dial-up. Telecommuting and working remotely also became the norm for millions of workers, mandating the need for enterprise applications to be able to work over those same broadband connections. As the numbers and types of applications continued to grow, so did security concerns. Enterprise firewall vendors proliferated as businesses of all sizes began to rely on the Internet for a growing number of needs. Firewalls started popping up not only in the company data closet but even on users machines in the form of software firewalls. With the acceleration of firewalls and their associated rules came the headache of managing those rules. Firewall administrators found themselves in the constant battle between making a firewall secure enough to keep the bad guys out, but flexible enough to allow authorized users to go about their business without getting blocked. The early home-broadband connections of the late 1990s found the cable or DSL modem connecting directly to the users pc. Soon home routers became the norm, adding the ability to share the connection with multiple computers in the home. Those routers added features like DHCP, Network Address Translation, and of course, consumer grade firewalls. With the addition of WiFi, even more devices in the home could connect to the Internet since the chains of having to run an ethernet cable were finally undone. Present day, 2012. Desktops, laptops, netbooks, tablets, TVs, gaming consoles, digital picture frames and even thermostats are just a sampling of devices

needing Internet access. But as the type and quantity of devices has grown, so have the restrictions. An online gamer might find himself having to navigate his PCs firewall, his broadband home routers firewall, and even his ISPs firewall. Both free and paid-for Internet access can be found outside the home in coffee shops (Starbucks), restaurant chains (McDonalds), airports, hotels, hospitals, and even cruising at 30,000 feet, but access almost always comes with acknowledgement of the terms of service and a least a basic level of firewall restrictions, if not much more. How Does a Firewall Work? If you stopped a dozen people on the street, chances are most if not all have heard the term firewall, yet very few people, even the technologically savvy, understand how one works. To understand firewall operation, first we need a basic primer on the TCP/IP protocol. Every Internet connected device must have an IP address. That address takes the form of a.b.c.d, where each letter represents a positive integer of 255 or less. An IP address can be public or private. In simplest terms, a public IP is one that exists on the public Internet, and a private IP is one on a private network. That private network could either be isolated (no Internet access) or the network could be connected to the Internet using Network Address Translation, a common feature found in home routers and corporate firewalls that allow multiple devices with private IP addresses to share one or more public IP addresses. For example, most home Internet routers area assigned a single public IP address by the consumers ISP, and that single IP address is shared by the multiple devices inside the home. The NAT functionality in the home router then translates from each private IP to the one public IP. When one device wants to communicate with another, it needs both the IP address of the remote device, as well as the port that the remote device is listening on. There are two types of ports, TCP and UDP, and they can be numbered anywhere from 1 to 65535, adding up to a total of 131,070 ports that two network devices can communicate on. Port designations are critical since they help keep traffic isolated for each of the many applications running on the given device. Think of ports as an old fashioned telephone operator sitting in front of a switchboard with 131,070 wires. The operator receives a call (traffic from the client device), and that call specifies the required port, and the operator (in this case the devices operating system) routes the traffic within the device to the appropriate application. For example, the default port for web browsing is TCP port 80. When a user types a URL into their browser, their computer does a DNS lookup and comes up with a list of IP addresses for that URL. If the user types in www.google.com, the DNS lookup process returns one of more IP addresses of Google servers. The

browser then sends network traffic (packets) to that server with a destination IP address from the DNS lookup and a TCP port of 80. If the user was sending e-mail with a common e-mail client, the destination for that traffic would be the IP address of his mail server with a TCP port of 25, which is reserved for the Simple Mail Transport Protocol (SMTP). Other common ports include TCP 23 (Telnet), TCP 110 (POP), TCP 443 (Secure HTTP), TCP 3389 (Microsoft Windows Remote Desktop), and UDP 67 (DHCP protocol.) For any operating system, whether its Microsoft Windows, Mac OS X, or Linux, only one application can listen on a port at a given time. The average server could have dozens of ports open for various applications it is supporting. Additionally, a single application could be listening on many different ports at the same time. The term firewall rule is most typically associated with a rule that either expressly permits or expressly denies traffic to traverse the firewall to a given IP address (or IP range) and port combination. Therefore if a university wanted to block an online game, and that online games servers listened on UDP 5000-5100, then by creating a firewall rule blocking all outbound (from inside the University firewall to the Internet direction) traffic, theyd prevent the user from connecting to the gaming servers. ISPs that provide home broadband connections frequently block a small set of ports. For example, Comcast blocks TCP/UDP ports 135-139 in both the inbound and outbound directions. That port range includes the Microsoft NetBIOS ports, frequently used for file sharing. Most residential ISPs in the United States also block TCP port 80 in the inbound (Internet to home user) direction in order to prevent their residential customers from hosting web servers in their homes. Of course, a home user hosting a web server could easily reconfigure his web server to listen on a different TCP port (such as 42500) that wasnt blocked in the inbound direction, but if so, hed need to make sure his users knew to specify the port in the URL. (i.e. http://www.daveshomeserver.com:42500) To summarize what weve learned so far, when one device (client) wants to talk to another device (server), the client sends traffic to a specific protocol (UDP or TCP), IP address, and port combination. While todays firewalls can block on many different parameters, the most basic of firewall rules can be triggered off of one or even a combination of the above parameters (Protocol, IP address or range, port number) and can be configured to apply that rule in either the inbound (Internet to private LAN) outbound (private LAN to Internet), or both directions. Inbound vs. Outbound Your average home user has a home broadband router which by default will usually allow almost all connections in the outbound direction, but few if any

connections in the inbound direction. That mode of operation makes a lot of sense since generally its the home user wanting to initiate a connection with the Internet in order to watch videos, browse the web, play a game, or check his mail. Its very uncommon for a server on the Internet to need to initiate a connection to a device inside the consumers home, however, those circumstances do exist and well cover them a bit later. The TCP and UDP protocols are both part of the TCP/IP protocol suite. TCP is a connection oriented protocol, while UDP is connectionless. Without getting into a long dissertation of the differences, think of it this way With TCP the two devices first need to agree that they want to exchange data, which results in a TCP connection. Each time one device sends traffic to the other, the receiving devices acknowledges (ACKs) it by sending a simple ACK message to the sender. Either sender or receiver can then tear down the connection at any time. With UDP, the sender just starts talking to the receiver, and in turn the receiver just starts replying. UDP messages between sender and receiver are not acknowledged so its up to the application itself to keep track of integrity of the communication and decide whether to ignore dropped packets or perhaps have the application itself retransmit the packets. TCP therefore has built in error protection because if the sender sends a packet and the receiver doesnt ACK it, the sender knows he needs to send it again. TCP takes much of the burden off of the application (web browser, mail client, etc.) to worry about whether all of the packets made it to the sender or not because the decision to retransmit is made at the operating system level (Windows, Linux, etc.) vs. the application level. But all of those ACKs create overhead and can limit the speed at which the traffic gets from point A to point B. UDP doesnt have that overhead, and is especially useful in applications where either waiting for an acknowledgement or trying to resend the traffic would either be undesired or unnecessary. Voice-over-IP services generally use UDP because its critical that the voice conversation can happen in real time with virtually no delay, so if some packets dont make it to the other end since they were somehow dropped along the way, while it may result in some moments of choppy voice, its still preferable to trying to resend the packets and then getting the two people on each end of the line out of sync with their conversation. The entire cable television industry operates off of UDP as well. Digital video signals are transported by a cable TV provider as UDP packets. If you have ever seen tiling on your screen (also referred to as pixelization) whereby the picture gets blocky momentarily, that is likely because some UDP packets were lost along the transmission path. While tiling isnt ideal, its still required for large scale TV channel distribution since TV is expected to be delivered in real-time therefore there isnt time for retransmitting lost packets. Additionally, most users would much prefer tiling and being able to continue to watch their TV show as opposed to sitting and watching a frozen TV screen as the

packets are retransmitted. Some popular VoIP and two-way videoconferencing applications will try to use UDP for their connections, but if the required UDP ports are blocked, they might revert back to common TCP ports such as TCP 80 or 443 since those ports are almost always open on any Internet connected network. Now that weve reviewed TCP and UDP at a high level, as well as covered the basics of a firewall rule, lets discuss some real-world examples. Joe is a home user with a cable broadband connection he accesses through his Linksys home router which is set up in a default configuration. Joe wants to do a search on Google so his points his browser to www.google.com. His PC therefore creates a TCP connection to TCP port 80 on the Google server. As long as this connection remains open, Joe can talk to the Google server, and the Google server can talk to Joe. If Joe closes his browser, the TCP connection also closes. Joe can easily re-launch the browser and talk to the Google server again, however, due to Joes firewall rules in his Linksys router, the Google server cannot talk to Joes computer again until Joe initiates a new connection. This is one of the most fundamental operating principles of a firewall. The firewall has a private side and a public side. The private side is protected from the public side by the firewall such that unless a device on the private side initiates a connection with a server on the Internet (public side), that server on the Internet cannot talk to the device behind the firewall on the private network. For TCP, the Linksys router (with built in firewall) keeps track of the TCP connections and will let the server on the public side continue to talk to the device on the private side until either the connection times out or one of the two sides tears it down. For UDP, many home router/firewalls have a UDP session table that somewhat mimics the tracking of TCP packets. When a client device on the private side sends traffic to the Internet, the router will record the key info of both devices (such as IP addresses and port numbers) in memory. As long as one of the devices sends traffic periodically, the router will allow traffic in both directions. If no traffic from either device passes through the router for a predefined amount of time (perhaps one to several minutes), then the router will remove the UDP session from memory and if the server on the public side tried to talk to the device on the private side, the servers packets would be rejected from the firewall. However, if the device on the private side sent one or more packets to the server again, the session would be put back into memory and the server could then once again to the client device. Open Ports vs. Port Forwarding Out of all of the many thousands of message board conversations and other postings the Firebind team has read over the years, if there is one topic that rises to the top of confusion, its the concept of opening a port and whether that means port forwarding. The reason behind the creation of this white paper was specifically to address this confusion, but the prior subject matter had to be reviewed before we could tackle this subject.

What amazes us the most isnt that so many individual users are confused, but major companies are either confused or dont do a thorough job of explaining what ports are needed for a given application. Clear and concise information about required ports for an application gets more and more critical every day as security threats continue to pervade the Internet and firewall rules get more and more restrictive. Cloud computing is helping corporations to host their critical applications outside of their own facilities, but that creates its own difficulties as a greater number of people need to use a wide variety of ports to reach those servers. As the pioneer in Internet Path Validation, Firebind subscribes to the following required minimum information about one or more required ports: Which protocol is required (TCP or UDP) Which port or ports are required for each protocol (port 1015, or ports 2000-2010, etc.) Which direction will the connection be initiated in outbound or inbound o Outbound from inside the firewall (private side) to outside (public, Internet side) Inbound from outside the firewall (public, Internet side) to inside (private side)

Its pretty incredible how often we see a list as basic as something like the required ports are 4300, 4400, and 4401. This level of brevity can do more harm than good. Which protocol is it? Which direction? Lets assume the port numbers specified for the application are both complete and correct. Lets further assume that the company went one step further and specified either UDP or TCP protocol for each individual port in their list. What that leaves us with is the question of which direction, and that question couldnt be more critical. From the perspective of a corporate firewall, it will likely need to have many rules permitting traffic to be initiated on the public side and terminated (received) on the private side. From the perspective of the server inside the company, the traffic is inbound. If a server inside the corporate data center is running Microsoft Remote Desktop, and that server sits on a private network behind the corporate firewall, then a firewall rule will need to be created such that traffic destined for TCP port 3389 (the default Remote Desktop port) will be forwarded from the public side of the firewall, through the firewall, and then on to that server running remote desktop. This is a classic example of what is called Port Forwarding.

Similarly, some online games allow users to host their own gaming servers so that user and a bunch of his friends can all play on the same server, allowing for a very fast response time. If that hosted gaming server is configured to be behind the home users firewall (on the private side), then the user needs to create port forwarding rules on a per port basis on his home router so that if packets arrive inbound (from Internet to the gaming server behind the firewall), the firewall will port forward those packets to his gaming server. The rule would essentially say if any traffic arrives on the public IP address of the router, and inside those packets the destination port is UDP Port xyz, then forward that traffic to the private IP address of this gaming server. The gaming server might need to support multiple ports so either multiple rules would be created or perhaps a single rule would allow for a range of ports to be specified. The good news is that corporate IT personnel wouldnt be employed to manage the network and the firewall if they didnt understand the concept of port forwarding, but the bad news is that the average home user gets confused by all of the misinformation on the Internet, and automatically assumes that when they are told to open ports or make sure their ports are open, that is means to set up port forwarding rules on their home router. If there is one concept the reader takes away from this whitepaper, this should be it. While port forwarding rules are extremely common in corporate settings, it is rarely needed in a home setting. Port forwarding is required for devices (such as a server) on the public Internet side of a firewall to INITIATE a connection with a device on the private side. However the need to do that is very rare since this would be a device initiating a connection in the INBOUND direction from the perspective of the user behind the firewall. Instead, what a user needs to make sure of is whether their device can communicate to the Internet on a given UDP or TCP port in the OUTBOUND direction. Thats it. Please re-read that sentence and commit it to memory because understanding that concept could have saved countless users hours and even days of frustration as they tried to get their latest online game working by adding unnecessary port forwarding rules, only to have it not help them connect to the gaming server. The very large majority of online games and virtually all major applications that a user might run on their machine do not need any port forwarding configured to work because the user is always initiating the connection, and once the user INITIATES the connection from their private side out to the server on the public side, two-way communication can them commence and continue for as long as both devices would like. Even for online games that might require port forwarding, its generally only when the users are hosting a gaming server, and not if the user is playing the game

through the company hosted servers. Unfortunately there are countless web sites on the Internet that only add to the confusion as they advertise to users to come here to check your ports, yet those tests only check whether port forwarding has been properly set up, which as stated above is only relevant a tiny fraction of the time. Port forwarding is clearly necessary for some applications, but its still relatively rare as compared to the entire user universe, even within the gaming community. But making sure your required TCP or UDP ports arent blocked in OUTBOUND direction is relevant 100% of the time. Now that weve reviewed the confusion around the frequently mistaken need for port forwarding (inbound direction), lets talk about the outbound direction. A home broadband user has 3 common sources of outbound port blocking. 1. A software firewall such as Windows firewall 2. A home router/firewall 3. The ISPs firewall Collectively these three are all part of the last mile of broadband. If none of those 3 potential firewall instances are blocking a given TCP or UDP port, then generally speaking the user should be able to communicate to any server on the Internet over those ports. The reason is that the group of entities (commercial, government, academic, etc.) that effectively make up the Internet generally dont block any ports in the core of the networks. If port blocking is going to be done by an ISP, generally its done at the edge of the network to prevent the traffic on the blocked ports from ever reaching the core, or reaching other users grouped together on the same edge. (The previous statements assume countries with unrestricted Internet access.) Many ISPs, at least in the United States, tend to block only those ports that are necessary for the security of the network and for other users. As stated earlier, many ISPs block ports related to peer-to-peer file sharing since they dont want to risk a person accidentally stumbling across his neighbors files. They also may block unrestricted use of TCP port 25 (SMTP) to prevent spammers from having an ingress to the Internet. Many ISPs also block a handful of other ports that might be associated with certain viruses that propagate over those given ports. In rare cases in the United States, an ISP might try to block applications that dont pose security risks, but instead pose risks to their business models by consuming too much traffic. Two applications that have occasionally gotten headline for being blocked by ISPs include Slingbox (streaming video) and BitTorrent (peer-to-peer file sharing.) For Slingbox users who found themselves blocked, assuming the blocking was done with a rule defined with the default Slingbox port, all a user had to do was change the default port to get around the block. That was

possible since the user owned and operated the Slingbox out of their home and had the ability to change the port. However, if the user is trying to reach a server over one or more ports and he doesnt control that server (such as in the case of a gaming server), then changing the server listening ports isnt an option. Various VPN or tunneling services exist to allow a user to tunnel through a firewall, but those services add complexity and delay since the remote end of the tunnel then needs to eject the traffic and direct it towards the end destination, resulting in a longer path and additional latency for all of the traffic. When a home broadband user has blocked outbound ports, it frequently can be traced back to either misconfiguration on the home router or on the software firewall on their home computer. Various applications can be allowed to update the firewall rules and it could be possible that in that process, certain UDP or TCP ports got blocked that should not have been. Other locations where a user may be accessing the Internet through a firewall include at their place of work (hence corporate firewall), at a school, college or university, or via a public Internet connection such as one in a hotel, airport, or coffee shop. Deciding outbound firewall rules for a corporation can range the gamut from lets only block a small handful of ports that are clear security concerns to lets block all ports by default, and then ONLY enable the ports we know for sure need to be opened due to the applications we run on our network. The latter is getting more and more common in the corporate environment and corporations try to minimize the possible effects of security issues like a virus infecting PCs and then trying to transmit information outside of the company, to more efficiency related reasons such as not wanting workers to spend any of the company time playing online games. Schools, colleges and universities can be all over the map as well. Some leave most ports open, while others go the more draconian route and lock everything down except what is authorized. Some popular gaming platforms even have entire message boards dedicated to users posting about their online gaming experience at different colleges around the world, and whether the game could connect through the college firewall or not. Public Internet such as WiFi hotspots in airports and coffee shops can vary widely as well. Since these connections are frequently free, some WiFi providers go so far as to block all ports except for TCP port 80, thereby only allowing web browsing on those connections, something that can frustrate the WiFi user when they cant make a VPN connection back to their company to check their mail. The single biggest problem with outbound port blocking, besides the blocking itself, is that very few applications are intelligent enough to tell the user why they

cannot connect to their respective server. Instead many applications might simply sit there for a minute or two and eventually say something like connection timed out or provide some useless error code like error 500932. Its very rare for an application to tell a user something like cannot connect to server since require port 17002 is blocked by a firewall. Some applications like some popular instant messaging products are able to operate over different ports or sets of ports, so if they cant connect at first, they try a new port or port range. Its a very useful feature but its not trivial to implement and hence isnt found very frequently. Firebind and the Art of Internet Path Validation The inspiration for Firebind came due to exactly one of the scenarios mentioned above working in a hotel room and trying to send mail over and over, never to be told by the e-mail application that it was a port blocking firewall rule preventing the mail transmission. But the one thing that all Internet connections have in common is allowing communication over TCP port 80 since that is the default port for web browsing. That led to an idea What if we built a client/server architecture that allowed a user to input a list of UDP or TCP ports or port ranges, and then have a server on the Internet listen on each port, one-by-one, for test traffic from the client to the server on each port in succession. The server would then receive the test traffic on the given port and echo it back to the client, and if the echoed payload matched what the client sent, the port would pass. If not, the port would fail. By using TCP port 80 as the command channel, the client could use that communication path for all of the port related administration and test setup so that even if every single port other than TCP port 80 was blocked, the client would still be able to communicate with the server to confirm the ports were failing. Firebind is the only cloud based solution in the world that can allow a user to test any port at any time. Additionally Firebind is architected to support thousands of concurrent users regardless of how many ports or the range of ports each user is testing. Firebinds patent pending technology seamlessly manages those user sessions and listener ports to provide unheard of scale and flexibility. How Do Users Test Open Ports Today Without Firebind? There are many solutions available today that claim to test for outbound ports, but dont come close to matching the flexibility and speed of Firebind. One reason is that Firebind operates using a very complex state machine that requires a significant amount of expertise to develop, maintain, and operate. Multiple, single-user, static solutions exist. In some cases a user sets up a custom listener app on a remote machine outside of the firewall, and then uses

either a custom client app, or even an open source application like Nmap to send packets to that listener application, which can then signal whether traffic was received on the given port or not. There are many drawbacks to this approach. First one needs to have full root access to a server on the public Internet. The tool can only be used by one client at a time, and validation of two-way traffic isnt a guarantee. Other websites and tool providers confuse the user with port scanning tools like Nmap which, on their own, are meant to scan a target machine for open listening ports, NOT validate whether traffic can pass through a firewall on a given port and reach a server on the other side. Firebind is often confused with port scanning tools which is why we consider Firebind a path scanning solution. Then of course there is the old telnet trick. This can actually work pretty well for validating an open TCP port. If you have a server on the other side of a firewall and its listening on a TCP port, you can telnet to that port and hit the return button a few times. If you see any sort of response, such as text, then chances are you are communicating through the firewall to that server on the other end. However that isnt a guarantee since the firewall or another device called a proxy server could be intercepting your traffic and replying to your telnet session. Thats why Firebind performs echo validation and by confirming that the test data we send is the exact date we receive back, we know for sure no device in between client and server is manipulating the data. Why Should I Use Firebind? Firebind operates on the premise that if you can communicate to the Firebind server on a given TCP or UDP port, then its not blocked by a firewall, and you can then use that same port or group of ports to communicate with your required server. Firebind offers several clients today: A Java Applet client that is accessed through a browser to test any UDP or TCP port A Javascript web client which can test most TCP ports (except the subset of ports each browser blocks for security reasons.) An Android client

Firebind users can enter their own list of ports to test or choose from a variety of preconfigured apps that include many of the most popular online games, various corporate applications, and traditional protocols such as Telnet, SSH, FTP, etc. Firebind has really been embraced by the online gaming community, a community which unfortunately has been confused for years by improper

instructions about port forwarding when all that was necessary was for the user to ensure they arent seeing any outbound blocking on the given ports. Firebind has made validating ports a 2 click operation the first click to navigate to the game specific test page, and a second click to start the test and validate whether the games required ports are blocked outbound or not. There is no guesswork of whether the ports are blocked or not. Firebind completes the test with a clear SUCCESS or FAILURE message, as well as a concise list of which ports passed and which failed, and for TCP, Firebind will also tell you how they failed (for example, did the firewall drop them silently or did it send a TCP RESET message telling the Firebind client it refused to set up a connection.) There is no need to download a file from the gaming provider and then install it and run it. Firebind is especially useful as users need to test and then retest as they might be investigating their home router or software based firewall rules. Its a very common occurrence to see a user perform multiple tests in a row that fail, and then finally the test will pass all ports as the user figured out his problem. Even though in many cases the problem a user has isnt related to blocked ports, the fact that they can rule out blocked ports so quickly is critical. The majority of times a car wont start isnt due to an empty gas tank. It could be due to a dead battery, a bad starter motor, a corroded spark plug, or one of a dozen other reasons. Its just not logical that a car owner would sit there for hours trying to figure out why his car wont start, only to find out it was because he was out of gas. That doesnt happen since he can rule out an empty gas tank but looking at the fuel gauge on the dashboard. But very few applications have that equivalent of a fuel gauge, so users do sometimes spend hours trying to figure out if their ports are blocked when in a matter of 30 seconds or less they could use Firebind to at least rule out one major potential problem. Firebind Summary Firebind is the most logical first step in any connectivity troubleshooting scenario. If you cant reach the Internet on the TCP and/or UDP ports your application requires, then nothing else matters. You need access to the proper road before you can worry about reaching your destination server, so why spend time making any configuration changes or investigating possible client-side application problems if a Firebind pass/fail result is only 30 seconds away.