Firstly, a disclaimer: This is based on my observation of behaviour for the Beta test. This is completely unofficial and not endorsed by anyone with a red name (tho authoritative updates would be most welcome!) It may be incomplete. It may be wrong. This sort of detail is subject to change at the whim of the developers and system admins inside SOE. And it probably won't be true or complete for release.
And another disclaimer: I use FreeBSD for my firewall, and while none of this should be OS-specific, don't ask me about setting up Linux or Windows ICS or other firewall systems; I can't help you.
And a warning: SOE have pretty heavy-duty intrusion detection and DOS prevention, so if you start poking around on these hosts, your IP will be banned for some period (an hour or more).
Start with the good news: Galaxies works fine from behind a firewall, even an port/address tranlation one. All connections and UDP streams are initiated from the client, so the NAT firewall has a chance to set up state before receiving anything from the server. There is no need for manual port forwarding for incoming packets/connections. If your NAT gateway is clever enough, you can even run multiple clients on the same LAN.
OK, on with the detail. I will present this in the order in which the connections occur when starting up the game.
First, the launchpad starts and connects to the patch server to patch up the launchpad:
lookup patch.station.sony.com (64.37.156.21)
tcp to patch.station.sony.com port 7000
The Launchpad uses HTTP protocol over this link. It first downloads an XML file containing the file version info, then downloads whatever files it needs.
Then, the launchpad puts up the licence agreement and the login screen:
nslookup sdlaunchpad1.station.sony.com (64.37.148.142)
udp to sdlaunchpad1.station.sony.com 3016-3019
(port 3019 is the launchpad chat server, 3016-3018 are the login server & galaxy status & stuff.)
Once you log in, the launchpad shows the status window. This window is just a web browser, so if your IE setup defines an HTTP proxy, this
proxy will be used. Otherwise, the launchpad makes a direct HTTP connection:
lookup starwarsgalaxies.station.sony.com -> foyer.station.sony.com
-> sdvirtual1.station.sony.com (64.37.156.19)
tcp sdvirtual1.station.sony.com port 80
Then the launchpad connects to the beta patch server and patches the actual game:
nslookup betapatch.starwarsgalaxies.com -> patch.station.sony.com
-> 64.37.156.21
tcp port 7070
All the patching is done via this link, including all the file transfers. This works the same way as the launchpad patching described above.
If you use the Launchpad bug report screen, this sends email to an SMTP server listening on an odd port:
lookup monitor-west.station.sony.com (64.37.132.11)
tcp to monitor-west.station.sony.com port 2525
Once you hit play, you get connected to the actual game servers. There are dozens of these. There are several physical servers per Galaxy;
apparently each physical server manages one planet or one area of a busy planet.
The West Coast servers all have names like
sdtswg-01-01.starwarsgalaxies.net
sdkswg-01-01.starwarsgalaxies.net
(note sdT vs sdK) and the -01-01 can be more-or-less any number (I've
seen dozens of different hosts, up to sdtswg-01-20 and sdkswg-07-15.)
It _seems_ the first number is the Galaxy, and the second number is the host serving part of this Galaxy. I.e. all the -01-xx hosts are Bria,
-02-xx hosts are Ahazi, etc. But this is just conjecture.
The sdt names all resolve to IPs in the 64.37.128.0/18 netblock.
The sdk names all resolve to IPs in the 199.108.0.0/20 netblock.
Both these netblocks seem to be in the same SOE facility in San Diego and connect via the same router (63.212.173.146), tho that may be an artifact of the ISP I use and the way SOE advertises their routes.
The East Coast server/s (Bloodfin in Beta) have names like
ablswg-01-01.starwarsgalaxies.net
again with dozens of variations for the -01-01 part.
These hosts are in netblock 199.108.192.0/20. According to Q-3PO, this is in Virginia (and the traceroutes seem to agree). rDNS does not seem
to be working on this net yet.
Connection to the game server is by UDP to a port in the range 44450-44469.
There are a couple of packets a second, and total traffic seems to be in the region of 4Mb/hour download and less than 1Mb/hour upload, tho
this seems to depend on where you are and what you are doing - sitting around a crowed cantina seems to use more data than wandering alone in the desert.
So, given all the above, these are the rules we use in our firewall (this may not make much sense unless you know FreeBSD's ipfw software):
mel2=10.132.4.0/24 (our internal network)
swg=64.37.128.0/18
swg2=199.108.0.0/16
# This combines the West 199.108.0.0/20 and East 199.108.192.0/20
# It also includes a heap of other nets from CERFnet, but I can live with that.
$fwcmd add allow tcp from $mel2 to $swg 80,7000,7070,2525 setup
$fwcmd add allow udp from $mel2 to $swg 44450-44469,3016,3017,3018,3019
$fwcmd add allow udp $swg 44450-44469,3016,3017,3018,3019 to $mel2
$fwcmd add allow udp from $mel2 to $swg2 44450-44469,3016,3017,3018,3019
$fwcmd add allow udp $swg2 44450-44469,3016,3017,3018,3019 to $mel2
|
Subscribe...
News...
