Unable to connect to Zone

ryujin · Post by **ryujin** » Thu Jul 19, 2012 5:33 pm

So I was trying to play a little bit between classes at my school.
Alleg loads up fine- but when I click on "free games" I get a message: "Unable to connect to Zone. Please try again later."
Any idea's/suggestions?

P.S. tried to use the "failedconnection.reg" file- still no workie

ryujin · Post by **ryujin** » Thu Jul 19, 2012 6:26 pm

"If you are behind a corporate, college, or university network, there is a strong chance that the ports required by Allegiance are blocked. Unfortunately, there is nothing you can do about this except for pleading with your administrator to open the ports for you. "

doah!

Post by **FreeBeer** » Fri Jul 20, 2012 9:17 pm

I find it odd that some schools would block those ports this day & age. It was a very common practice years ago (probably gaming was seen as improper use of the connection - that and the bandwidth pressures they caused back then.) I don't run into this as frequently as I used to, but I imagine that there's a few hold-outs. Still, you might want to verify that you're being blocked. Ports 2300-2400.

ryujin · Post by **ryujin** » Mon Jul 23, 2012 9:01 pm

mind walking me through how to verify?

Post by **FreeBeer** » Mon Jul 23, 2012 10:08 pm

Ryujin wrote:QUOTE (Ryujin @ Jul 23 2012, 06:01 PM) mind walking me through how to verify?

Hope this helps:

QUOTE 07-06-2004
Use GRC ShieldsUP! at http://grc.com/.

Detecting Ports Blocked by Your ISP

Internet service providers often block specific traffic entering their
network before it reaches their customers, or after leaving their customers
before it exits their network. This is sometimes done to block the
exploitation of common security vulnerabilities, and sometimes to prevent
their customers from offering proscribed Internet services.
As a customer, it can be useful and interesting to know which service ports,
if any, an ISP has chosen to preemptively block in order to restrict their
customers' global Internet traffic.
ISP port blocking can be easily tested, often quite rapidly, by arranging to
allow the ShieldsUP! probe to have access to an unprotected computer. Since
all non-stealth machines will respond to every open request - either
affirmatively or negatively - ports appearing as STEALTH will be those
blocked by your ISP, corporate firewall, or other external agency.

If your system is unprotected, without any personal firewall or NAT router,
any ports showing as stealth are being blocked somewhere between your
computer and the public Internet. This is probably being done by your ISP.
Internet traffic directed to your computer at the stealth ports will be
dropped before reaching your machine.

If your system has a personal firewall that can be instructed to "trust" a
specific remote IP, you can temporarily instruct it to trust the ShieldsUP!
probe IP of [204.1.226.228]. If, after doing so, most of the service ports
change to either open or closed , you have succeeded and any which remain
stealth are being blocked by your ISP.

If your system is operating behind a residential "NAT" router, the router
will be acting as a natural and excellent hardware firewall. But that's not
what you want for the moment. You can temporarily remove your NAT router and
connect an unprotected computer directly to your cable modem or DSL line.
Or, if you are comfortable reconfiguring your NAT router, you may be able to
point the router's "DMZ" at one of your computers which has been instructed
to "trust" our probe IP of [204.1.226.228]. If, after doing so, most of the
service ports change to either open or closed , you have succeeded and any
remaining stealth are being blocked by your ISP.

Finally, if your Internet security system, NAT router, personal firewall,
or whatever, can produce detailed logs of incoming Internet packets, you
could leave your existing security in place, clear your log, run the service
ports scan, then carefully inspect your log for any consistently missing
port probes. We send out four sets of probing packets because individual
packets are sometimes dropped along the way. Therefore, it won't be unusual
to see occasional missing packets from your logs. What you're looking for is
a complete lack of packets bound for a specific port. A careful and detailed
examination of your log will reveal any missing ports which are being
blocked before they reach your logging tool. (Note that this technique is
not quite as foolproof as the other approaches since ISPs could be blocking
outbound packets from their customers, which the other approaches would
detect but log-watching would not.)

After completing the experiments above, remember to return your system to
its previous tight security and verify that everything is safe again by
re-running any of our tests.[/quote]

MonAG · Post by **MonAG** » Mon Jul 23, 2012 10:14 pm

I am not too literate in these matters, but can´t you run into trouble if the university detects you are port-scanning the network? Just curious.

Spunkmeyer · Post by **Spunkmeyer** » Mon Jul 23, 2012 10:21 pm

No. Portscans are routinely blocked by firewalls depending on the rate, other than that nobody will pay any attention... besides the scan above is not originating from your IP.

Post by **pkk** » Mon Jul 23, 2012 10:31 pm

I've visited the campus website and it looks like you're going online via a proxy server. You have to log in with username/password to get internet access, so I don't see a chance (except HTTP tunneling, but that sucks) getting Allegiance working behind it.

ryujin · Post by **ryujin** » Mon Jul 23, 2012 10:47 pm

pkk wrote:QUOTE (pkk @ Jul 23 2012, 05:31 PM) I've visited the campus website and it looks like you're going online via a proxy server. You have to log in with username/password to get internet access, so I don't see a chance (except HTTP tunneling, but that sucks) getting Allegiance working behind it.

this http tunneling would result in all kinds of lag?