Jump to content
  • Advertisement
Sign in to follow this  
tomva

Best way to open ports in Linux?

This topic is 3173 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all- I'm trying to build an engine where people (real people, not just developers) can run servers and clients at will. Is there any way to make that easy for people? (This is on Linux for now, but eventually Windows as well). I don't think most people are going to want to (or be able to) do a lot of configuration to open and close ports. For instance, if I tell people "just install the game and then here are some iptable commands" I'm probably dead in the water. What do games do to run servers on arbitrary ports and then have clients connect? Also, in the meantime as I'm testing, what is the best way to quickly allow particular TCP and UDP ports? The SELinux UI was very painful--messing with iptables on the command line would be easier! I just want to say "let me send/receive TCP on port 5099 and UDP on port 5098" for instance. -Thomas

Share this post


Link to post
Share on other sites
Advertisement
Ubuntu 9.04 doesn't come with a firewall on, 9.10 will come with an easy to use firewall which you can easily give your users instructions for. I'm not too familiar with Fedora, but as I recall it includes an easy to use firewall as well, on version 10 and 11.

Both Fedora and Ubuntu are, as distrowatch seems to indicate, the most popular Linux distributions out there, another big one recently is Linux Mint which is based on Ubuntu and so will probably require similar instructions.

If you limit your support to Fedora(plus variants) and Ubuntu(plus variants) you'll cover a good share of your linux users without too much trouble. Just install virtualbox, create a virtual machine for each OS and use them for testing.

Share this post


Link to post
Share on other sites
Generally, the firewalls will let programs communicate outwards, even with UDP (although on Windows, it'll ask the user to allow it the first time).

Because users will be running servers, and almost all users are behind NAT, you will need to solve that using NAT punch-through, which in turn means that you need an external introducer. From the point of view of the firewall (and your NAT router), the "server" will look like a client -- that's the whole point of NAT punch-through! Thus, you don't necessarily need to do anything particularly fancy to deal with the "common case."

You may want to document all the uncommon cases, though -- users who need to set up port forwarding through the external router, users who need to allow the port specifically, etc. You may be able to detect a bunch of those cases manually in the installer, and tell the user what to do.

Share this post


Link to post
Share on other sites

Hmmm. NAT punch-through is a good solution, although won't work for my initial use case (people running their own servers with no other external server available). But my initial use case is just LAN play, so I think it's fine if everyone has to be behind the same NAT, or if someone wanting to support a WAN game has to set up their server to be accessible outside the NAT.

My server needs to open a TCP listening port, and also send and receive on a UDP port. The client connects to the server's TCP port, and sends and receives on its own UDP port.

I guess I'll do this:

  • Recommend standard TCP and UDP port numbers to use (I'll just pick two port numbers above 1024 that aren't commonly used). People running a server can pick their own port numbers but the default will be the recommended standard ports. This is so that people can open those ports on other firewalls if needed.
  • Publish good how-to's so people running servers can update their local firewall to allow the server to accept connections. Ideally the server itself will do some auto-detecting and provide diagnostics to help. Many linux distros today include local firewalls so I'll need to help people configure those, even for LAN play.
  • If someone running a server wants to support WAN play, they need to make their server visible to the WAN. There will be some how-to's for this, but clearly it will be a more advanced use case.
  • People running clients shouldn't have to do anything.


In the future, I can look at NAT punch-through to make WAN play easier.

My remaining question: is any configuration required for clients? In particular, how does the UDP interaction work? Can clients receive UDP packets back from the server without any firewall configuration?

Share this post


Link to post
Share on other sites
In most cases, clients will be able to receive UDP packets back in response to outgoing UDP packets.

However, certain firewall policies will not allow any traffic that is not part of a "strong positive" list of applications. Under such policies, your traffic would not get through. However, automatically circumventing such policies is probably not in the best interest of the user -- a strong policy, if present, is there for a reason.

Share this post


Link to post
Share on other sites
"I don't think most people are going to want to (or be able to) do a lot of configuration to open and close ports. For instance, if I tell people "just install the game and then here are some iptable commands" I'm probably dead in the water."

If you package the game as (say) a DEB or an RPM, people are pretty used to typing in their password to confirm the installation -- at which point their privs get booted to being sudo root. So your install/uninstall scripts can do things like look if iptables is running and if so, install some new rules. (And take them out on uninstall).

Users who are of the ilk to install TGZs are used to reading some instructions and will understand the need to "sudo ./install_firewall_rules" after unpacking things.


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!