[Rack] Fwd: Noisebridge Closed Ports

Dr. Jesus j at hug.gs
Tue Sep 7 15:38:12 UTC 2010

On Tue, Sep 7, 2010 at 12:19 AM, Jonathan Lassoff <jof at thejof.com> wrote:
> On Tue, Sep 7, 2010 at 12:06 AM, Andy Isaacson <adi at hexapodia.org> wrote:
>> On Mon, Sep 06, 2010 at 11:42:25PM -0700, Help (rudy) wrote:
>>> >         On 9/2/10 6:19 PM, Iskundar Haddad wrote:
>>> >>         Could you guys open up the following ports for noisebridge at
>>> your convenience:
>>> >>         UDP 1200    (used for friends service)
>>> >>         UDP 27000 to 27015 inclusive
>>> >>         TCP 27020 to 27039 inclusive
>>> >>         TCP 27040 and 27041 only for CyberCafe Owners
>>> >>
>>> >>         super very much appreciated,
>>> >>         -Isky
>>> Iskundar,
>>> [1] Looking at our firewall, we are blocking NO ports.
>>> [2] we are doing natting...
>>>     outbound for all your internal IPs maps to:
>>>     I set the inbound for those ports you listed to map like this:
>>> port# --> port#
>>> Whoever manages your box at noisebridge can do whatever
>>> they want with those inbound packets.
>>> As always, please test and make sure I did this properly.  :)
>>> Rudy
>>> PS, I cc'd Andy as I know him but I don't think I have met you, Iskundar.
>> Thanks Rudy.
>> Isky, could you hop on rack at lists.noisebridge.net and discuss what
>> you're trying to do?  Me and Jof and Rubin break^H^H^H^H^Hfix most of
>> the networking stuff at NB, and I'd prefer we not bug our (completely
>> donated!) ISP contacts with random questions.
>> Most likely what you're running into is something on our Soekris or
>> related...
> Yes, as far as I can tell, no ports should be outright blocked right now.
> Also, the currently configured default ISP is Sonic.net, not Monkeybrains.
> The only place I can imagine UDP traffic getting dropped would be from
> the queueing rules on the routers/NAT boxes. They prioritize certain
> classes of outbound traffic (SSH/TCP port 22, TCP ACKs, Jabber/XMPP,
> and AOL IM/OSCAR), and all other traffic is carried as "best effort",
> meaning it will be sent if there is room in the outbound queue.
> Come to think of it, the queue could probably use a little bit of
> tweaking since Dr. J enabled Annex M on the Sonic.net link (giving us
> some slightly faster upstream). I'll take a look at that now.

Already taken care of.

> Isky, does it seem like something is breaking or being blocked? What
> are you observing?

The problem is that he's either trying to host a dedicated
Source-based server or trying to connect to one and it's not working.
In the former case we'd have to have specific configuration rules for
his machine, which isn't going to happen.  In the latter case
static-port has to be enabled in the firewall configuration since the
protocol uses the matching src/dst port trick to punch UDP packets
through the firewall.  Due to that protocol design decision, when two
players behind the same NAT box connect to the same service with
static-port enabled you get all kinds of weird problems because the
NAT state tables can't disambiguate the response packets.  Turning
static-port on globally can cause those weird problems for protocols
other than Source game packets, by the way, and we're not going to do

Political reasons aside, the protocol is simply not designed to work
in our network environment with multiple users all speaking different
connectionless protocols behind a NAT.  Isky needs to use Hamachi or a
VPN box or something. Sorry Isky, there's nothing we can do on our
side without affecting everyone else on the network.

For the record, I don't want Noisebridge to turn into a Starbucks or a
lan cafe either.  It sets a precedent that we're just square feet and
not a community.  That being said, I learned a lot by taking games
apart in debuggers when I was younger, and those skills have
repeatedly proved invaluable in my line of work.  If people are at
Noisebridge *creating* networked games, I'll move heaven and earth to
give them the tools they need.

More information about the Rack mailing list