Some time ago, shortly after iPhone OS 3.0 was released, we received a number of reports from users that our VPN-based wireless service had become unusable. For those not familiar with this service, OWL is one of our local wireless networks that permits VPN access for university members whilst providing a captive-portal for visitors. Normally the dual-use works quite well: university members start the VPN client and visitors start a web browser to log in.
Not so for OS 3.0 users though, who joined the wireless service only to be automatically shown the visitor login page, and then when they closed that down the iPhone or iPod Touch would just disconnect from OWL in a huff. There was no opportunity to start the VPN client.
A mail list post by James Hooper, a Network Specialist at Bristol University, explained all: it seems the device tests for Internet connectivity by attempting to retrieve a specific web page. So all we need to do is trick OS 3.0 into thinking this page is accessible.
According to James, the page in question lives at http://www.apple.com/library/test/success.html and should return the following, to be considered a success:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>Success</TITLE> </HEAD> <BODY> Success </BODY> </HTML>
We know that all clients attempting HTTP requests on OWL will hit our captive portal web servers. These servers are already configured to capture URLs and redirect clients to the Visitor Network login page. All we need do is configure those servers to first check for a request to success.html and return the fake content instead. The excellent mod_rewrite Apache module comes to our rescue, and we end up configuring something like the following:
# apple captive portal detection RewriteRule ^/library/test/success.html$ - [L]
The above line tells Apache that if the request matches this text, then it should stop processing and serve the file locally (a copy of success.html is saved on the server). Just after that instruction, we capture every other request and issue a 302 redirect to the captive portal login page.
I’m told that Apple did acknowledge this bug, and perhaps even fixed it in OS 3.1, although brief tests were not conclusive. Regardless, it’s better for us to leave this monkeypatching in place to avoid users having further difficulties in connecting.