Using Apple Products with Captive Portal
-
Hey Folks,
I'll start by saying that i'm very new to PFSENSE but not networking and routing. I've a custom Captive Portal Page setup that works perfectly in the sense that it prompts captive page which I just have a terms and conditions and a Connect to Wifi button on it. No authentication is used inthe Captive Portal Configuration.
The issue I'm experiencing is specifically with iPhones and iPads. Haven't test (heard complaints) about samsung devices. Once connected and through the portal page on an iPhone or iPad browsing works perfectly and a lot of apps work fine however the likes of the Facebook App can't connect.
Has anyone seen this issue before and if so does anyone have a fix or solution they would like to share.
Cheers,
TQ -
Because Bitten Fruit suxxx. Whitelist www.apple.com in CP.
-
Sounds simple. Apologies however for how stupid this may sound but I can't find a section in Captive Portal Config to Whitelist a website. Any hints on where I would find it.
-
Ok folks I was just tired and stupid. I used the allowed hot name section to whitelist www.apple.com but no joys. Anyway I've another branch to this question. Is the captive portal feature in the latest release of pfsense a complete implementation?? Is there a captive portal 2.0 on the way that will better handle the likes of mobile devices and such.
-
Sorry, but once again, Apple is simply retarded. And getting way more retarded lately, read about the CP "improvements" in iOS7.
This is a completely wrong place to complain, plus not exactly something to be fixed in pfSense.
-
Ok point taken. Bitten fruit are poxy at best.
Explain to me then when Alcatels captive portal in the same network as my newly added pfsense box allows all traffic from all apps.
It's probably some firewall rule that the I'd not visible to is. Regardless it needs sorting.
-
people who apply the "retarded" label to a corporation seem… retarded.
-
There is a workaround for Apple "improvements".
After googling and reading some forums I came across this
http://forum.daviddarts.com/read.php?9,8879,8910#msg-8910
https://github.com/PirateBox-Dev/PirateBoxScripts_Webserver/blob/stable/piratebox/piratebox/www/library/test/success.html
I don't have Apple product on hand, but I changed Firefox useragent to emulate it and got it working.
What I did is that I inserted right below
expire.url = ( "" => "access 50 hours", ) EOD;
the following code into /etc/inc/system/inc starting at line 1121
$lighty_config .= "\$HTTP[\"useragent\"] =~ \"CaptiveNetworkSupport\" {\n"; $lighty_config .= "server.document-root = \"/usr/local/www/library/test/\"\n"; $lighty_config .= "index-file.names = ( \"success.html\" )\n"; $lighty_config .= "dir-listing.activate = \"disable\"\n"; $lighty_config .= "server.error-handler-404 = \"/success.html\"\n"; $lighty_config .= "}\n";
This is not maybe 100% correct place and code can be more elegant, but I'm not PHP coder and this is the only way I was able to get it working.
Also, you have to create /usr/local/www/library/test/success.html
<title>Success</title> Success
When CP enabled, I would get regular CP authentication page if I use default useragent. When I change useragent to CaptiveNetworkSupport I would get success.html page.
Can somebody look into this solution, test it, fix code and maybe if that turns to be ok submit it as bug or feature. As I said, I'm not coder.
-
Strange.
Running a hotel. See many devices - also the "fruit" related. I even use an iDevice to the test portal - and all AP's ….
I never had any problems, this one, 2.1.2-RELEASE or even the older ones (1.x.x series).
I just checked, and I have NO url's like www.apple.com white listed.
Please note that iOS checks if it has a "Internet connexion" by hittin a site and it isn't always "www.apple.com" that's being used (it was before). Other urls are also used tested.So, I conclude that there must be another reasons if iDevices wont take the portal as any other WiFi device.
Btw: the portal interface was always present in pFSense, as pfSense is derived from M0n0Wall, several years ago.
-
There is a workaround for Apple "improvements".
After googling and reading some forums I came across this
http://forum.daviddarts.com/read.php?9,8879,8910#msg-8910
https://github.com/PirateBox-Dev/PirateBoxScripts_Webserver/blob/stable/piratebox/piratebox/www/library/test/success.html
I don't have Apple product on hand, but I changed Firefox useragent to emulate it and got it working.
What I did is that I inserted right below
expire.url = ( "" => "access 50 hours", ) EOD;
the following code into /etc/inc/system/inc starting at line 1121
$lighty_config .= "\$HTTP[\"useragent\"] =~ \"CaptiveNetworkSupport\" {\n"; $lighty_config .= "server.document-root = \"/usr/local/www/library/test/\"\n"; $lighty_config .= "index-file.names = ( \"success.html\" )\n"; $lighty_config .= "dir-listing.activate = \"disable\"\n"; $lighty_config .= "server.error-handler-404 = \"/success.html\"\n"; $lighty_config .= "}\n";
This is not maybe 100% correct place and code can be more elegant, but I'm not PHP coder and this is the only way I was able to get it working.
Also, you have to create /usr/local/www/library/test/success.html
<title>Success</title> Success
When CP enabled, I would get regular CP authentication page if I use default useragent. When I change useragent to CaptiveNetworkSupport I would get success.html page.
Can somebody look into this solution, test it, fix code and maybe if that turns to be ok submit it as bug or feature. As I said, I'm not coder.
This is cleaner version. I forced myself to read through some stuff about PHP.
Replace this
$lighty_config .= << <eod<br>## error-handler for status 404 #server.error-handler-404 = "/error-handler.html" #server.error-handler-404 = "/error-handler.php" ## to help the rc.scripts server.pid-file = "{$g['varrun_path']}/{$pid_file}" ## virtual directory listings server.dir-listing = "disable" ## enable debugging debug.log-request-header = "disable" debug.log-response-header = "disable" debug.log-request-handling = "disable" debug.log-file-not-found = "disable" # gzip compression compress.cache-dir = "{$g['tmp_path']}/lighttpdcompress/" compress.filetype = ("text/plain","text/css", "text/xml", "text/javascript" ) {$server_upload_dirs} {$server_max_request_size} {$fastcgi_config} {$cgi_config} {$captive_portal_mod_evasive} expire.url = ( "" => "access 50 hours", ) EOD;</eod<br>
with this
$lighty_config .= << <eod<br>## error-handler for status 404 #server.error-handler-404 = "/error-handler.html" #server.error-handler-404 = "/error-handler.php" ## to help the rc.scripts server.pid-file = "{$g['varrun_path']}/{$pid_file}" ## virtual directory listings server.dir-listing = "disable" ## enable debugging debug.log-request-header = "disable" debug.log-response-header = "disable" debug.log-request-handling = "disable" debug.log-file-not-found = "disable" # gzip compression compress.cache-dir = "{$g['tmp_path']}/lighttpdcompress/" compress.filetype = ("text/plain","text/css", "text/xml", "text/javascript" ) {$server_upload_dirs} {$server_max_request_size} {$fastcgi_config} {$cgi_config} {$captive_portal_mod_evasive} expire.url = ( "" => "access 50 hours", ) \$HTTP["useragent"] =~ "CaptiveNetworkSupport" { server.document-root = "/usr/local/www/library/test/" index-file.names = ( "success.html" ) dir-listing.activate = "disable" server.error-handler-404 = "/success.html" } EOD;</eod<br>
-
I've tested the solution above and while it works for a success page redirection it doesn't work for allowing the likes of Facebook, Youtube or twitter apps on iOS devices. Looks like i'll have to wait for an apple "update" to hopefully do something that fixes this.
Cheers for the help guys
TQ -
I've tested the solution above and while it works for a success page redirection it doesn't work for allowing the likes of Facebook, Youtube or twitter apps on iOS devices. Looks like i'll have to wait for an apple "update" to hopefully do something that fixes this.
Cheers for the help guys
TQThis solution is not intended to fix your Facebook problem. It is workaround for Apple's "CP improvements" as described on many other forums as well as here before. Maybe I hijacked your thread with this, sorry. I don't use/own Apple products, so I cannot test anything, but if you do some packet capture and post it here maybe we can come up with some solution.