ZOIS *
Technical Notes
ZOIS Technical Note TN-2010-01-15
Author and Audience
This is for iPhone owners who have access to 'open'
Wireless Local Area Network (WLAN) which is non-the-less heavily
firewalled. A relatively knowledgeable audience is assumed, for it is
a bit of geeky-fiddle. Written by Martin Sullivan[au], ZOIS Limited, Cockermouth.
Abstract
The Apple iPhone appears to do some odd things when confronted by
an apparently open but firewalled WiFi network. Some trickery is
required to make it behave 'normally'. Circumventing the firewall
requires the use of a StrongSwan VPN, which is documented elsewhere.
Introduction
Wireless LAN activity extends to Stag House where routers have been set up to fully open, in that no authentication or encryption is used at the link-level (WPA or WEP). Connections are allowed only via certificated authenticated SHH[sh] and until recently through OpenVPN[ov]. Other activity is blocked up-stream by a firewall system that redirects Web traffic to a local server that informs:
Welcome to ZOIS WLAN web-site. This site is visible from the local (to Stag House) Wireless Wireless Local Area Network (WLAN), but there's not a lot to see. If you're visiting this site via WLAN you'll find yourself confined to it and unable to visit anything else. If you want to do anything more, you'll have to contact us and discuss ssh tunnels, or Virtual Private Network (VPN) set-ups.
We will call this the "WLAN text" for future reference.
A recently acquired Apple iPhone[ip] was added to
the mix, but it was found that WiFi (as it is termed on this platform)
would not connect properly, forcing the user to go to some
authentication web-site under the apple.com domain and shutting down
WiFi should this not be successful, as it will be in the
ZOIS system. Some experiments were made and a solution
found. The actual setting up of a VPN connection is described
elsewhere.
Materials and Platform
Linux (root access required), iPhone (OS 3), Iptables, StrongSwan,
Apache (with mod_rewrite installed and enabled).
Method
While the Wireless routers are open they use a subnet on the wired
side (10.192.0.0/24) which is heavily firewalled. The only activity
that is allowed is DNS, which is required to allow named connections
to occur. Should somebody connect with the Wireless network, then use
or attempt to use the Web, they get the WLAN text notice that their
connection attempt was unsuccessful, and by inference that
ZOIS are no slouches when it comes to computer
programming. The iptables(8) rule which allows this is:
iptables -t nat -A PREROUTING -i eth1 -s 10.192.0.0/24 -p tcp \
--dport --webcache \
-j REDIRECT --to-ports 80
iptables -t nat -A PREROUTING -i eth1 -s 10.192.0.0/24 -p tcp \
--dport http \
-j DNAT --to 10.192.0.1
|
When the users arrive on 10.192.0.1 they see a web page with the WLAN text message. They see this whatever page they've asked for because the page is also the error page. The Apache configuration for that is:
ErrorDocument 404 /index.html ErrorDocument 403 /index.html |
When the iPhone automatically assesses the WiFi connection they appear to issue a HTTP GET request to http://www.apple.com/library/test/success.html. This is issued by a User Agent 'CaptiveNetworkSupport' and it does not attempt to use any proxy that may be configured on the iPhone. This attempt will obviously result in a 404 failure and the WLAN text. After this the iPhone attempts to connect to www.apple.com again, this time through Safari to some-kind of login page, again resulting in the WLAN text. The WiFi link on the iPhone is then discarded.
It was clear that initial connection needed to succeed. When that connection was attempted a single page of HTML is returned which has the word 'Success' in it. Once this behaviour had been characterised casual Internet searching found that several people had noted this behaviour as well[mt, re], and speculated upon its meaning. What is clear is that Apple fail to document it.
Since the iPhone needs a positive response to its strange little query it was decided to give it one. Mod_rewrite[rw] was found convenient in this regard and the following would redirect the initial query to the 'correct' HTML supplied locally.
RewriteCond %{HTTP_HOST} ^www\.apple\.com [NC]
RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport.*
RewriteRule /library/test/success\.html http://rose.zois.co.uk/success\.html [L,R]
|
With this in place the iPhone seems happy to allow regular WiFi
connections to be made and the WiFi connection remains
established. Its behaviour is now one where the casual browser attempt
results in the WLAN text message. To get further a Virtual Private
Network VPN is required. Although the standard here at
ZOIS is a UDP based OpenVPN, the iPhone is not so
equipped. It was decided therefore to use a IPSEC PPP tunnel system
based on L2TP and StrongSwan[ss]. This has
fortuitously has been documented elsewhere with extremely readable
notes and explanations by Niels Peen[np]. And we do
not think that we can improve upon this safe to say that NAT-T is
essential, so recompilation is required; we used a slightly older
version of StrongSwan for our server uses an older, but in service,
version of Ubuntu. We also found that /etc/ppp/chap-secrets needs to
have the same password as l2tp-secrets (the lines are
identical). Attention should be given to spelling and correctly
adjusting Niels' examples with your local information, lest, like us,
you fall into the trap of trying to connect to 'your.ip.here' and such
like.
Discussion
A small amount of speculation has been placed on the Internet at
large as to the meaning of the strange initial WiFi behaviour of the
iPhone. Without any meaningful input from Apple, however, it remains
just that. Speculation. It kind of makes us paranoid though. A small
amount of geeky-reconfiguration locally allows us to circumvent
whatever Apple are up to.
References
References found in this section, and in particular the HTML links were correct at time of writing (2010-01-30).
$Date: 2010/01/29 18:23:55 $