KGS Issue - Firewall

If you can't play on Go servers like KGS because ports are blocked by a firewall, the easiest solution is to enable the firewall to allow connections via port 2379 to goserver.igoweb.org .

Another option would be use a server like GoShrine, as it has been designed to be firewall friendly.

These links may provide further helpful information:

Connecting through firewalls

KGS Issue - HTTP Tunnel
KGS Issue - SSH Tunnel

Anonymous:allowing TCP traffic to port 2379 to goserver.gokgs.com should work if you can surf this page without problems

The following conditions should apply to the program javaw.exe.

• If you use a router: Allow its IPS in both directions for UDP and the used port.
• Allow direction Out, files.gokgs.com OR goserver.gokgs.com OR www.gokgs.com, TCP, remote port 80.
• Allow direction In OR Out, goserver.gokgs.com, TCP, remote port 2379.
• Allow direction In OR Out, goserver.gokgs.com, UDP, remote port 53.

Depending on how exactly you connect to KGS, possibly not all conditions are necessary. In fact, one wonders why (at least some particular version of) CGoban wants that many.

wmsIt doesn't want that many. All you need is outbound traffic from your host to goserver.gokgs.com port 2379. The other ports are standard web server ports (if your firewall blocks them, then you're in trouble anyway).

Actually, port 80 *is* a problem: a browser will happily use a proxy, but CGoban doesn't have an option to.

KGS has never used any UDP port. I have no idea why you think UDP to port 53 is needed.

Velobici: UDP port 53 is used for DNS lookups. Presumably, for converting goserver.gokgs.com to its IP address. Your computer should already have access to your local DNS servers vi a UDP port 53. If not then you will not be able to reach any URL by name in place of IP address. You can try starting CGoban3 , clicking on the Configure button. There you will see that the Host is goserver.gokgs.com and the Port is 2379. To see if DNS blocking is a problem, open a DOS window and enter the command nslookup goserver.gokgs.com; you see the IP address 74.52.20.154 in the response. You can try replacing goserver.gokgs.com in the CGoban: Configure window with 74.52.20.154.

213.73.68.48: Or one can set the IP instead of the URL in one's firewall. - wms, what are the calls of files.gokgs.com and www.gokgs.com good for? Are the usernames and login passwords stored there?

CGoban (javaws, really) checks www.gokgs.com to see via http if there is a new version of the client. When you open the login window, the MOTD is fetched from files.gokgs.com. But again, these are standard http accesses, if your firewall doesn't allow them then you probably can't browse the web at all to get the clients in the first place!

213.73.68.48: The KGS client, once started, works with fewer rules. Presumably the TCP / 2379 does it. The requests to the three kgs URLs with ports 80 (TCP) or 53 (UDP) were reported by my firewall when calling the login to KGS via the CGoban.exe startup window, from which one could also call edit Go editing features instead. Of course, I don't know whether CGoban or javaw itself requires these ports or UDP; the program communicating with KGS is javaw.exe, if I believe my firewall, which does not show CGoban's activity at all. So I conclude that CGoban calls javaw's internet capability and lets it do the internet thing. Of course, I am not in trouble with browing the web, because I would not use javaw for that purpose. In fact, javaw's only connection to the internet is on request of CGoban. Everything else is too risky, in my opinion, although I would rather prefer not to use Java at all for that matter.

Velobici: Risk is a function of operating system and applications. What do you use for browsing the web?

213.73.68.48: Some standard browser with fewer gaps than Internet Explorer.

Sinprejic: I don't believe you when you say that there is a port 53 udp TO the kgs servers. What are you using for a firewall program? If it's some commercial GUI windows firewall it almost certainly is telling you what server is being looked up via port 53 udp. The request would be sent to your service provider's machines, not to KGS. This would be a reasonable way to present the information about that packet since DNS lookups are one of the most common types of network traffic. Since they are almost always are directed at the DNS servers your ISP provides, or the ones you configure in your TCP/IP settings for a static setup, saying where the request went is a waste of time. This means that the server to which port 53 requests are sent is always the same (or always one of 2-3 IPs), and the only interesting thing about such a request is what name it is looking up. Thus a "user friendly firewall" is quite likely to present the name of the server being looked up (interesting), not the name of the server to which the lookup request was sent (boring). If you are in a portion of the program where you are reading port numbers (something most users never do) the firewall author probably assumes that you are a net admin and know that 53 is DNS, 80 is http, 443 is https, 22 is ssh, etc... here's a link to a version of the standard linux /etc/services file that tells you what everything is... http://iptables-tutorial.frozentux.net/other/services.txt

If your machine *is* making lots of requests on port 53 to machines other than your configured DNS hosts, you may have a virus or other malicious program (which might be misrepresenting itself as almost any process, including java).

dencarl: Wow, there's a lot of FUD on this page. Here is an explanation of how DNS works. Since the address is goserver.gokgs.com there will be 3 DNS lookups. The first request on port 53 is to the 'root nameserver' to get the IP for the Top Level Domain (TLD) ".com". Obviously that result will be cached so it might not occur very often. The second request on port 53 is to the '.com TLD nameserver' to get the IP for "gokgs.com". The third request on port 53 is to the 'nameserver for gokgs.com' to get the IP for "goserver.gokgs.com"