Breaking the internet (hotels, guestnet style)

Joe Greco jgreco at
Tue Dec 8 03:39:18 CST 2009

> In message <200912080332.nB83WKSo037049 at>, Joe Greco writes:
> > > IMHO there is no need for any sort of DNS redirection after user 
> > > authentication has taken place.
> > 
> > It may be hazardous even before user authentication has taken place.
> > Even given a very low TTL, client resolvers may cache answers returned
> > during that initial authentication.
> > 
> > > We of course redirect UDP/TCP 53 to one of our servers along with 80 
> > > (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any 
> > > authentication has occurred, but once this is completed the only reason 
> > > any guest would use the local DNS server is if they were assigned a DHCP 
> > > address.
> > 
> > Which, presumably, many/most of them are.  Supplying a functional DNS
> > server shouldn't be that difficult, but real world experience shows just
> > how well some operators run these services.
> > 
> > > As far as our Routerboard/Mikrotik setup works, it'll masquerade for any 
> > > non standard IP addresses that appear on the network (guests with static 
> > > ip's assigned, corporate laptops etc) but once again after the 
> > > authentication stage anything is allowed to pass unhindered.
> > > 
> > > The only redirection that is used after authentication is for port 25 as 
> > > 90% of user trying to send mail out via port 25 have no idea how to 
> > > change their mail server, let alone why they might need to.
> > > It can be an issue as some systems use authentication on port 25.
> > 
> > Sounds like an opportunity for a custom proxy.  Clients that can
> > successfully authenticate to an external mailserver on 25 are probably
> > by definition nonproblematic.  The remainder probably deserve to get
> > jammed through an aggressive spam, virus, and other-crap filter, with
> > in-line notification of rejections.  You can do some other sanity stuff
> > like counting the number of hosts contacted by a client; anything in
> > excess of a small number would seem to be a good indicator to stop.
> This really should be a DHCP option which points to the authentification
> server using ip addresses.  This should be return to clients even
> if they don't request it.  Web browers could have a hot-spot button that
> retrieves this option then connects using the value returned.
> No need to compromise the DNS or intercept http.

But that doesn't change the fact that there's a need; it's a part of the 
flawed design of the various components, because this problem wasn't 
envisioned and solved and now we have a mess.  Even the hotspot vendors 
cannot agree on a unified way to do things; this means that each network
you try to connect to will implement its own set of unique brokenness,
ranging from requirements for a particular OS/browser, use of reserved/
allocated IP spaces for stupid reasons (hi,!), various DNS/HTTP
attempts at redirection, blocking, etc.

I know what you're saying, but seriously, haven't we just repeated all
the same mistakes in IPv6?  And of course it'd be a nightmare to cover
all the edge cases, this is why nobody tries to figure it out, so in
the end we end up with many really cruddy hatchet jobs.

Why would "web browsers" have a hot-spot button?  What if I want to
just use ssh?  And where's the web browser on my VoIP telephony 
adapter, etc?  :-)

It's gotta be difficult for the hotspot networks.  Even at&t can't seem
to make it all work right even when they control both sides; I've seen
iPhones just hang when connecting to attwifi (and I can say I've seen
it not work in some way maybe even more often than I've seen it actually 
work).  At least the iPhone seems to have some built-in support for this
sort of thing.  (Anybody know anything more about that?)

... JG
Joe Greco - Network Services - Milwaukee, WI -
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

More information about the NANOG mailing list