On Fri, 2 Jul 2010 22:07:03 -0400 Rob Owens <row...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100704003916.9a4ebd2b.cele...@gmail.com
