Re: Connecting to the exterior network is impossible `directly'
On Fri, 2 Jul 2010 22:07:03 -0400
Rob Owens <rowens@ptd.net> wrote:
...
> I think the solution was to use opendns servers in /etc/resolv.conf.
> The reason it works is that, according to the article I read, many of
> these captive portal systems work by not giving you a dns server until
> you enter your credentials. If you manually specify your own dns
> server, you can avoid entering your credentials.
>
> I've never tested it, but I know that the captive portal systems I've seen give you an IP
> address before you enter your credentials. In fact, they have to give
> you an IP address otherwise you couldn't get to the "credentials"
> webpage.
>From http://en.wikipedia.org/wiki/Captive_portal#Implementation
-----
Implementation
There is more than one way to implement a captive portal.
[edit] Redirection by HTTP
If an unauthenticated client requests a website, DNS is queried by the
browser and the appropriate IP resolved as usual. The browser then
sends an HTTP request to that IP address. This request, however, is
intercepted by a firewall and forwarded to a redirect server. This
redirect server responds with a regular HTTP response which contains
HTTP status code 302 to redirect the client to the Captive Portal. To
the client, this process is totally transparent. The client assumes
that the website actually responded to the initial request and sent the
redirect. [edit] IP Redirect
Client traffic can also be redirected using IP redirect on the layer 3
level. This has the disadvantage that content served to the client does
not match the URL. [edit] Redirection by DNS
When a client requests a website, DNS is queried by the browser. The
firewall will make sure that only the DNS server(s) provided by DHCP
can be used by unauthenticated clients (or, alternatively, it will
forward all DNS requests by unauthenticated clients to that DNS
server). This DNS server will return the IP address of the Captive
Portal page as a result of all DNS lookups.
The DNS poisoning technique used here, when not considering answers
with a TTL of 0, may negatively affect post-authenticated internet use
when the client machine references non-authentic data in its local
resolver cache.
Some naive implementations don't block outgoing DNS requests from
clients, and therefore are very easy to bypass; a user simply needs to
configure their computer to use another, public, DNS server.
Implementing a firewall or ACL that ensures no inside clients can use
an outside DNS server is critical.
-----
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: