[itistoday]

I'm making a multiplayer game for OS X. In the game users will all interact with one another. I'm currently using UDP for this interaction. However, firewalled users of course need to forward their ports to receive information. How does one get around this? I know that games like Quake 3 Arena and many others somehow achieve this without the need for port forwarding.

[Thinine]

I think it's a tech called UPnP that will automatically open firewalls. But I really have no idea.

[Tritium]

Most firewalls are stateful (or at least fake it decently.)

The client sends a UDP packet first and the server replies back to the client on the same port that the packet came from. The firewall keeps track of what outbound source/destination ports it used and which IP address behind the firewall it will forward future packets to.

The tracked UDP connections usually time out after at least a few minutes, and interactive traffic will keep resetting the timeout so that the server's communication with the client won't be broken.


Just occurred to me - what kind of communication model are you using? If you're going to have one server and many clients this method works. With multiple clients all communicating directly amongst one another there is no way to magically punch holes in a firewall on both sides. You will have to forward ports. Games that don't require you to forward ports (like Q3A, all MMORPGS, etc) have a client server model.

[itistoday]

You're right, I should have mentioned that. The game could potentially have over 100 clients all talking to eachother, and they will each talk to a single server as well. However, to minimize load on the server, certain communication will be client to client only, and this is the communcation that I am having problems with. So, in the game, each client will talk to all the other 99 clients, and they will also be able to talk with the server, but, I want to minimize traffic to the server so data like coordinate location will be client -> client only.

There has to be some way to get around the firewalls?

[__^^__]

Your users will have to create an INBOUND ANY rule for the other clients to initate a connection. Simple stuff...

[itistoday]

Originally posted by __^^__:
Your users will have to create an INBOUND ANY rule for the other clients to initate a connection. Simple stuff...

No sure I understand you

[__^^__]

The firewall will need to be configured to allow the client UDP through to the localhost. Since it would not be practical to create a seperate rule for each client that could talk to a host, a generic rule which allows your UDP traffic from ANY host needs to be created. With personal router/firewalls, this is called port forwarding. How are the clients going to discover other clients running your software??

[itistoday]

Oh, I know what port forwarding is, that's exactly what I want to avoid. I don't want the user to have to fiddle with their router settings.

[Brass]

Originally posted by itistoday:
There has to be some way to get around the firewalls?

The whole purpose of the firewall is to make this impossible. If you found a way around it, it would be a bug - a security hole - and would have to be fixed by the firewall vendor.

The reason it's possible in a client/server model is that the communication to the client is merely in response to the communication from that client to the server (which firewalls do allow, of course).

[itistoday]

No, it wouldn't be a security hole. I know some games do this. And there are ways, so it's not impossible. I even know of a method but don't really like it due to its complexity: You use non-firewalled users as relays to transfer information to the firewalled users.

[Brass]

Originally posted by itistoday:
No, it wouldn't be a security hole. I know some games do this. And there are ways, so it's not impossible. I even know of a method but don't really like it due to its complexity: You use non-firewalled users as relays to transfer information to the firewalled users.

Yeah, or you use non-firewalled ports to relay to firewalled ports. Whatever. But he specifically said he didn't want to use forwarding.

I guess it's all semantics, but I wouldn't call that "getting around the firewall". I'd call that working within the limitations of the firewall. But it's all in the interpretation.

[ideasculptor]

If a firewall does not allow inbound connections, no amount of hacking is going to allow you to establish a connection to a client behind that firewall without discovering a security flaw or having the client set up a rule allowing such a connection from outside.

Some games may allow other, non-firewalled clients to act as a communication server, so that firewalled clients can ESTABLISH a connection to the other client instead of to the server, but such a system still relies upon the firewalled client connecting OUTBOUND to a server process listening somewhere else. There is no getting around it. If a firewall does not allow a SYN packet to reach the client, there will be no connection. Once a connection is established, you can push data to the client. The firewall doesn't insist on 1-way communication, just one way connection establishment.

--sam

[Tritium]

ideascuptor described it exactly - any game that has client to client communication that seemingly works through firewalls does some negotiation beforehand to determine which clients are not firewalled. The ones behind firewalls then connect to the non-firewalled ones.

There is no way to "trick" a configuration with a firewall on each side into allowing connections between the machines. That's the whole point of a firewall. The app will require that firewalls be configured to forward ports to the internal machines.

As an aside:
Client to client communication is a bad idea for gaming, it causes the problems you're running into, and in addition to that, two people behind the same NAT can't play with other people on the internet even if they can configure the firewall. They will have internal IP addresses, so if they report their true addresses, internet hosts can't connect back. If they report their internet facing IP, the two computers on a LAN together can't communicate.


Client to server is much easier to implement and support.

[itistoday]

Originally posted by Tritium:
Client to server is much easier to implement and support.

And more expensive. These firewalls suck. Sounds to me like it's just bad programming of the TCP protocol or whatnot; they should allow multiple people behind a NAT to be able to connect, the packets should just have the correct routing info.

[Tritium]

Originally posted by itistoday:
Sounds to me like it's just bad programming of the TCP protocol

Sounds to me like you do not know of what you speak. You miss the point of a firewall.

[ideasculptor]

Originally posted by itistoday:
And more expensive. These firewalls suck. Sounds to me like it's just bad programming of the TCP protocol or whatnot; they should allow multiple people behind a NAT to be able to connect, the packets should just have the correct routing info.

Multiple people behind a NAT box can connect. What they can't do is advertise their own IP address, since it is likely not a routable address, and even if it is routable, odds are good that the NAT is configured to not allow incoming connections.

If, on the other hand, several clients behind a NAT each advertise the NAT's address (which is likely the only routable address on the network), then how will a connection to one of those boxes be differentiated from the others?

The whole point of firewalls, whether implemented via NAT or not, is to control inbound TCP connections. NAT also hides the actual address of the host behind a common address. If a client behind the firewall starts a connection, then it is perfectly possible to send packets BACK to that host, on the same connection. What isn't possible is to create a new connection to a host behind the firewall. That is, after all, the whole point of a firewall. If arbitrary hosts could make arbitrary connections to hosts behind a firewall, how, exactly, would that firewall be doing anything useful? Anybody on the internet could connect to any protected host and use any service that is enabled. Hardly security.

You should really attempt to gain at least a rudimentary understanding of networking and network protocols. Without that, you aren't ever going to write a truly effective and efficient network application, no matter how good the API is.

I'll repeat. You CANNOT connect to a host behind a firewall unless someone makes an explicit rule on the firewall allowing that connection, either by allowing any host to connect to that port, or by allowing a specific host to connect to that host. There is no getting around that fact without hacking through the firewall, in which case, you've exposed a security flaw, not a feature.

--sam

[itistoday]

Originally posted by ideasculptor:
You should really attempt to gain at least a rudimentary understanding of networking and network protocols. Without that, you aren't ever going to write a truly effective and efficient network application, no matter how good the API is.

I resent this. I do have at least rudimentary knowledge of networking. I understood all of your explanations about how clients can only establish outbound connections from within firewalls, and not receive them—before I posted here. I understand the concept of a NAT, etc. However, I don't see the problems I'm encountering as a feature. At the very least, firewalls should allow some sort of standardized interface to them whereby a program can connect to them (software and hardware firewalls), and by giving them a password supplied by the user, automatically open all the necessary ports. That would be awesome, and fix my problems.

As I said before, I know of one way to "get around a firewall" in my problem, and that's by having a firewalled client establish a connection to a non-firewalled client, and use it as a relay for information. However, this work-around has its own problems that keeps me from implementing it.

So, from this thread I gather I'm just going to have to deal with it, and come up with a tutorial for each type of firewall the user may have and tell them how to foreward their ports.

[Wiskedjak]

I know absolutely nothing about these things, so take what I'm about to say with a grain of salt, but would it be possible to build into the game a client for an already existing instant messaging framework, such as MSN Messenger?

[proton]

I'd recommend you read Application Design Guidelines for Traversal of Network Address Translators by B. Ford of MIT, P. Srisuresh of Caymas Systems and D. Kegel of kegel.com.

This is an Internet Draft, so it'll disappear from there 6 months after it was posted (that'll be August 2005). This is a great document for you to read in relation to this problem, it should give you a number of ideas.

There are a number of other related documents referenced as well.

- proton

[ideasculptor]

Originally posted by itistoday:
At the very least, firewalls should allow some sort of standardized interface to them whereby a program can connect to them (software and hardware firewalls), and by giving them a password supplied by the user, automatically open all the necessary ports. That would be awesome, and fix my problems.

Then you clearly have never worked in a corporate network. No network administrator is going to purchase a product that would allow an average user on the network to open a hole in the firewall. For one thing, why should an administrator trust your app. If your app has mailicious code in it, he's no exposed his entire network, never mind whatever kind of antics users of your app could get up to by sending data down a connection established in that way. FOlks with 20 years of experience still write code that is susceptible to the occasional buffer overrun, are you really so confident that your communication protocol would be immune from such flaws? That is why no administrator is going to allow an application to automatically open a connection through a firewall. It would be network suicide. They wouldn't let a trusted app from Adobe, Microsoft, or Oracle have such permission, so they certainly aren't going to let some game do so.

There is a simple solution, and it is to write a communication server that all clients connect to for communication. It is the nature of network and network programming that simple things get hard when you try to scale them up to many users. Using a client/server model is a pain in the ass if you are going to scale above the number of users that can be handled by a single comm server, but that is the fun of network programming. They are interesting and entertaining problems to solve.

And the person who suggested using an existing IM protocol is dead oright. I am sure that there are both client and server side libraries for doing instant messenger type applications already available. Just grep around Sourceforge and download whicever sounds the closest to your needs.

--sam

[itistoday]

Originally posted by ideasculptor:
Then you clearly have never worked in a corporate network. No network administrator is going to purchase a product that would allow an average user on the network to open a hole in the firewall. For one thing, why should an administrator trust your app. If your app has mailicious code in it, he's no exposed his entire network, never mind whatever kind of antics users of your app could get up to by sending data down a connection established in that way. FOlks with 20 years of experience still write code that is susceptible to the occasional buffer overrun, are you really so confident that your communication protocol would be immune from such flaws? That is why no administrator is going to allow an application to automatically open a connection through a firewall. It would be network suicide. They wouldn't let a trusted app from Adobe, Microsoft, or Oracle have such permission, so they certainly aren't going to let some game do so.

You misunderstand me completely. This isn't an exploit, or a security hole. People on corperate networks would not be able to use this application to open up ports, because they would not have the administrators password. The only thing a standardized interface would allow applications to do is make it easier for users to forward ports necessary to the application. If you have the password to your firewall, then it's most likely your firewall to begin with. A lot of times home users buy routers but don't know how to use them for things like port-forwarding. With this interface, you would launch the program, the program would ask for the firewall's password, and it would ask the user's permission to open the necessary ports. That way, no matter what kind of router/firewall the user has, all applications would be able to access all firewalls in a standardized way that makes things easy for the user.

[ideasculptor]

That's just one more exploitable security hole, for minimal gain. People use games on all kinds of networks. The way to solve this is by making outbound connections, not automating port forwarding in firewalls. Security companies would never adopt such a thing, since there is no upside for them (minimal sales increase) and a significant risk. I see your point, but it just doesn't make sense in either a fiscal or security context. With outbound connections, your app can at least control which machines it communicates with (given an uncompromised DNS system, anyway) by only establishing connections with a particular address. With an inbound port forwarded, ANY remote host could connect to the app, which is far less secure. You'd be wide open to any number of attacks that can't exist when only outbound connections exist, not the least of which would be a SYN flood, which doesn't even require that you accept the connection to disable the machine.

One of the benefits of a client/server app where connection establishment is unidirectional is that you only have to protect one side, the server, where things are centralized, under your (the developers) control, scalable, and easily protected. It is much more difficult to protect n clients than 1 server, or even a cluster of servers.

--sam

[itistoday]

Originally posted by proton:
I'd recommend you read Application Design Guidelines for Traversal of Network Address Translators by B. Ford of MIT, P. Srisuresh of Caymas Systems and D. Kegel of kegel.com.

This is an Internet Draft, so it'll disappear from there 6 months after it was posted (that'll be August 2005). This is a great document for you to read in relation to this problem, it should give you a number of ideas.

There are a number of other related documents referenced as well.

- proton

Thanks for the link, I'll read over this

Edit: Wow, so far, reading just the first couple paragraphs, this seems exactly what I needed.

Here's an excerpt from the introduction:

Such application protocols
require "peer-to-peer" communication directly between arbitrary
hosts, and not just traditional "client/server" communication between
an arbitrary "client" host and a "well-known" server with a global IP
address and DNS name. RFC 3235 [NAT-APPL] already proposes some NAT-
friendly design guidelines for applications, but merely recommends
against using peer-to-peer communication without providing a workable
solution to this problem.

Given the increasing demand for applications that require P2P
communication, in conjunction with the ubiquity of NATs, applications
are increasingly implementing and deploying various workarounds to
this problem. Most of these workarounds take the form of a NAT
traversal or "hole punching" algorithm, by which two "peers" lying
behind one or more NATs cooperate with a well-known "rendezvous
server" to set up a direct peer-to-peer communication path between
them.

See ideasculptor? This is a real problem.

[itistoday]

Originally posted by ideasculptor:
That's just one more exploitable security hole, for minimal gain. People use games on all kinds of networks. The way to solve this is by making outbound connections, not automating port forwarding in firewalls. Security companies would never adopt such a thing, since there is no upside for them (minimal sales increase) and a significant risk. I see your point, but it just doesn't make sense in either a fiscal or security context. With outbound connections, your app can at least control which machines it communicates with (given an uncompromised DNS system, anyway) by only establishing connections with a particular address. With an inbound port forwarded, ANY remote host could connect to the app, which is far less secure. You'd be wide open to any number of attacks that can't exist when only outbound connections exist, not the least of which would be a SYN flood, which doesn't even require that you accept the connection to disable the machine.

One of the benefits of a client/server app where connection establishment is unidirectional is that you only have to protect one side, the server, where things are centralized, under your (the developers) control, scalable, and easily protected. It is much more difficult to protect n clients than 1 server, or even a cluster of servers.

--sam

Just because the port is forwarded doesn't mean the machine can be compromised, otherwise we'd have no servers at all. However, in my situation, I want to absolutely avoid having all clients talk through the server to each other, because I don't have that kind of bandwidth. So the clients have to talk amongst themselves. The game is also fast pasted, so I would prefer things to go over UDP. The only way for this to work is for the ports to be forwarded apparently. So I guess the other option is to have each client make 100+ TCP connections to all the other clients... BUT, how are two firewalled clients going to talk to each other then? They can't, so they'd have to communicate through the relays I described earlier (non-firewalled clients). However, this causes problems like lagging, connection dropping, etc.

So far, my understanding is that there's no way to get around this problem, besides having communication going through the server, but that's not an option. So it seems I'm going to have to make them forward the ports? And if that's the case then I might as well stick to UDP+port forwarding tutorials.

Edit: Or... you can use the techniques as described by the link given by proton!

[Brass]

Originally posted by itistoday:
However, I don't see the problems I'm encountering as a feature. At the very least, firewalls should allow some sort of standardized interface to them whereby a program can connect to them (software and hardware firewalls), and by giving them a password supplied by the user, automatically open all the necessary ports. That would be awesome, and fix my problems.

What you've just described is called a "Virtual Private Network" (VPN). This does completely circumvent the firewall, if the VPN server allows it. However, the machine outside the firewall, must have the correct VPN authentication information (and software) to connect to the machine within the firewall.

This, again, would not suit arbitrary connections that you want.

And this makes sense.

Arbitrary connections from an un-authenticated outside machine is exactly what a firewall is supposed to stop.

[ideasculptor]

Originally posted by itistoday:
Thanks for the link, I'll read over this

Edit: Wow, so far, reading just the first couple paragraphs, this seems exactly what I needed.

Here's an excerpt from the introduction:

See ideasculptor? This is a real problem.

I never said it wasn't a problem, I just said that you aren't going to find a fix, other than to develop your software with the problem in mind. Even the 'direct communication link' referenced in that article is just two hosts making outbound connections to an external host, which forwards packets between them. Client/Server, just like I suggested.

It is relatively easy to make a very high performance packet forwarder. All that is required is to slap a new sequence number on an incoming packet, recalculate the checksum, and put it back on the wire. No need to bring the packet up the network stack at all, if you have access to the tcp/ip stack (ie. use linux or BSD). You can't be quite so sneaky if you want a random, non-firewalled user to act as pcket forwarder, since you will have to bring each packet up into the application layer in order to forward it, and that is much more expensive, computationally, increasing latency and limiting scalability. But then, a single user probably wouldn't route much traffic, anyway. The problem with this is that, in a game environment, any user acting as a packet forwarder is going to lose CPU and bandwidth to communications, so who is going to volunteer to do that? Assuming you have a checkbox somewhere saying "Are you behind a firewall" which enables or disables packet forwarding, players who want maximum performance (and all players want maximum performance) will quickly figure out that pretending to be behind a firewall will provide better performance and will disable the comm-forwarder feature.

When I worked at Cisco (1996-2000), I tried to convince folks there that a box that does nothing but act as a packet forwarder for clients constricted by a firewall was a good idea. No one there doubted me, but there was significant doubt (probably quite well founded) that such a product would make money. This was long before the days of peer to peer applications, but I was bumping into the problem when writing my own game. I didn't want to host a server just to enable peer to peer network play. A simple protocol for establishing a connection is all that would be required to enable communication. A slightly more complex clustering algorithm could allow a bunch of packet forwarders to be seen on the network as a single 'virtual' packet forwarder, allowing good scalability of the system. I was working on a clustering product for Cisco at the time, so that was simple enough. In fact, you could use that mechanism to implement this today, since it is installed in every Cisco router.

However, the market forces just weren't there. The big game companies were perfectly capable of implementing their own systems for fairly little money (this isn't a copmlicated problem to solve, just a potentially expensive one, depending upon usage), and the small time folks weren't going to pay large sums of money for a prepackaged solution from Cisco.

To have one peer act as a forwarder for other peers may well work, depending upon the application requirements, but it is still client/server. The code is identical. The only thing that changes is whether you run that code on a server managed by you or one of the client peers. And what happens if there aren't enough peers without a firewall to host all the necessary traffic?

--sam

[ideasculptor]

Originally posted by Brass:
What you've just described is called a "Virtual Private Network" (VPN). This does completely circumvent the firewall, if the VPN server allows it. However, the machine outside the firewall, must have the correct VPN authentication information (and software) to connect to the machine within the firewall.

I think he's talking about an application INSIDE the firewall sending an authentication token to the firewall which would cause the firewall to open a port for any host (or set of known hosts) to connect on. Again, exactly what a firewall was designed to prevent.

More like a virtual public network, rather than a virtual private one.

--sam

[proton]

Originally posted by ideasculptor:
I never said it wasn't a problem, I just said that you aren't going to find a fix, other than to develop your software with the problem in mind. Even the 'direct communication link' referenced in that article is just two hosts making outbound connections to an external host, which forwards packets between them. Client/Server, just like I suggested.

Uhm. No.

One of the major methods described involves a rendezvous server to find out public IP/port combinations, but then using the approximately simultaneous connection attempts technique creates a connection directly between two peers behind NAT firewalls. See section 2.3.

- proton

[itistoday]

Originally posted by ideasculptor:
I never said it wasn't a problem, I just said that you aren't going to find a fix, other than to develop your software with the problem in mind. Even the 'direct communication link' referenced in that article is just two hosts making outbound connections to an external host, which forwards packets between them. Client/Server, just like I suggested.

.... snip ...

To have one peer act as a forwarder for other peers may well work, depending upon the application requirements, but it is still client/server. The code is identical. The only thing that changes is whether you run that code on a server managed by you or one of the client peers. And what happens if there aren't enough peers without a firewall to host all the necessary traffic?

--sam

No... read the article. As proton just said, it is a completely different method that involves connections directly between clients, without any "packet forwarding".

[itistoday]

Originally posted by ideasculptor:
I think he's talking about an application INSIDE the firewall sending an authentication token to the firewall which would cause the firewall to open a port for any host (or set of known hosts) to connect on. Again, exactly what a firewall was designed to prevent.

More like a virtual public network, rather than a virtual private one.

--sam

No, I'm talking about a standard interface to the firewall. It's not a security risk in any shape/way/form. There is virtually no difference between what I described and when a user connects directly to 192.168.1.1 and configures the router manually. The only difference is that the client application, through a standard protocol to all routers, would be able to connect to the router, give it the password provided by the user, if authenticated it would ask the user's permission to forward all the necessary ports. Perhaps the confusion is with the term "user". The user in this situation is essentially the system admin (because they have the router password).