Since the login page itself must be presented to the client, either that login page is locally stored in the gateway, or the web server hosting that page must be "whitelisted" via a walled garden to bypass the authentication process. Depending on the feature set of the gateway, multiple web servers can be whitelisted (say for iframes or links within the login page). In addition to whitelisting the URLs of web hosts, some gateways can whitelist TCP ports. The MAC address of attached clients can also be set to bypass the login process.
There is more than one way to implement a captive portal.
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  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.
Client traffic can also be redirected using IP redirect on the layer 3 level. This is not recommended as the content served to the client does not match the URL
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.
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.
Platforms that have Wi-Fi and a TCP/IP stack but do not have a web browser that supports  cannot use many captive portals. Such platforms include the Nintendo DS running a game that uses Nintendo Wi-Fi Connection. Non browser authentication is possible using WISPr, an XML-based authentication protocol for this purpose, or MAC-based authentication or authentications based on other protocols.
There also exists the option of the platform vendor entering into a service contract with the operator of a large number of captive portal hotspots to allow free or discounted access to the platform vendor's servers via the hotspot's walled garden, such as the deal between Nintendo and Wayport. For example, VoIP SIP ports could be allowed to bypass the gateway to allow phones to work.
Wipo Publishes Patent of Facebook for "Captive Portal State Detection and Avoidance for Multiple-Interface Traffic Offloading" (American Inventors)
Jul 01, 2013; GENEVA, July 1 -- Publication No. WO/2013/096146 was published on June 27.Title of the invention: "CAPTIVE PORTAL STATE DETECTION...
AirTight Adds Wi-Fi Captive Portal/Walled Garden to Its Cloud-Based Secure Wi-Fi and PCI Scanning Service; Announcement at 2011 PCI SSC North American Community Meeting.
Oct 04, 2011; At the opening of the 2011 PCI SSC North American Community Meeting in Scottsdale, AZ, AirTight[R] Networks, the leading provider...
US Patent Issued to Symantec on July 2 for "Method and System for Detecting Captive Portals" (Canadian Inventors)
Jul 02, 2013; ALEXANDRIA, Va., July 2 -- United States Patent no. 8,479,263, issued on July 2, was assigned to Symantec Corp. (Mountain View,...