Dear all

we would appreciate your help regarding the following problem:

IOS7 uses the Captive Network Assistent (CNA) function to recognize if the hotspot is open or if there is a captive portal.
When connecting to a wireless network the Apple iOS device sends a request to a specific page on the Apple Site to verify Internet connectivity.
• If the page is accessed successfully, the device assumes it has network connectivity.
• In the event of a failure, CNA assumes a captive portal and launches a CNA browser to prompt the user with the Splash Portal.

In IOS6 you could avoid the problem opening the domain apple.com in the walled garden of the captive portal.
In IOS7 this trick doesn't work anymore, whitelisting a specific URLs will no longer be sufficient since the list of those domain is very long (Cisco says more than 200... and of course the list of URLs is not publicly available!).

As a result this causes Login problems to our hotspot infrastructures.

Some rumors says that Cisco Meraki has an embedded feature for avoiding this problem (they whitelisted the complete list of test domains) Ref: http://blogs.cisco.com/wireless/get-you ... -for-ios7/ and http://www.cisco.com/en/US/products/ps1 ... e93c.shtml. So when you connect to a Cisco Meraki Hotspot you should not experience this problem.

Is there any chance that Mikrotik can do something about it, as it is crucial to our hotspot installations due to the fact that more than 50% of the devices are IOS devices.

Looking forward to your thoughts and suggestions.

Best Regards.

Thanks for pointing this out cellfinity. Tested with an iPhone on IOS7 and the only difference we see is that the login page pops up automatically once connected (we specifically disabled this by bypassing the success page in the walled garden for older devices). It's not preventing the login from working though - can you provide any detail on the login issue this is causing you?

Is there any chance that Mikrotik can do something about it, as it is crucial to our hotspot installations due to the fact that more than 50% of the devices are IOS devices.

I am also interested in Mikrotik solution to this problem. The iOS Login page must be prevented from appearing at all, as it just confuses users. Attempts to cancel the Login returns the user to the Wi-Fi settings on the device, so more confusion.

I do not require login; the user must have full access to the browser after Wi-Fi connection.

When connecting to a wireless network the Apple iOS device sends a request to a specific page on the Apple Site

In iOS7 the request is actually sent to a random URL on a randomly chosen Apple site, but always returns the same content.

Whitelisting the Apple domains is not a solution, for at least two reasons:

1. The domains are impossible to predict. There is no reason to assume that the small list of known domains will not be changed or added to and the devices updated; and

2. Whitelisting the domains assumes that the LAN is connected to the Internet. It does nothing for applications where the LAN is isolated from the Internet and cannot reach the Apple sites.

Hi Jarosoup and thank you for the interest.

You see as you wrote below with older IOS6 devices all needed was to allow traffic to a specific apple.com URL but with IOS7 Apple decided to randomnly check about 200 URLs using a protocol known as WISPr (which we know very little about). The problem is that our external captive portal uses cookies, and unfortunately cookies are not supported anymore in IOS7 mini popup browser (CNA)! that causes us login problems. So there are 2 ways to avoid this:

1. To inform the users that they must disable the auto login function inside our SSIDs WIFI connection information - that is on their IOS7 device settings - which they don't seem to like it so much...

or

2. Have RouterOS detect those WISPr packets and reply in such a way that IOS will think that there is no hotspot captive portal behind the wireless network connected. In that way the users will have to open safari and that is when they will be redirected to our external portal.

Having users to open safari is OK (for now) for us, as safari supports cookies which are vital for the operation of our portal (Until we modify it, but that takes time!!!)

I hope now the problem is better understood.

Best Regards

Hello to all of you,

and may I say that strahlen's post, reasons and assumptions are absolutely correct. Mikrotik or someone must do something about that and the only possible solution we can think is some sort of an algorithm that identifies WISPr packets and replies in a "positive" manner in such a way that IOS thinks that there is internet connection.

Meanwhile after the support we received from Mikrotik and another source we have managed to trick IOS7 devices by adding the following rules in our walled garden

/ip hotspot walled-garden
add comment="place hotspot rules here" disabled=yes add dst-host=static.ess.apple.com path=/connectivity.txt
/ip hotspot walled-garden ip add action=accept disabled=no dst-host=captive.apple.com add action=accept disabled=no dst-host=www.appleiphonecell.com
/ip hotspot walled-garden
add disabled=yes add dst-host=*.apple.com
/ip hotspot walled-garden
add disabled=yes add dst-host=www.itools.info
/ip hotspot walled-garden
add disabled=yes add dst-host=www.ibook.info
/ip hotspot walled-garden
add disabled=yes add dst-host=www.airport.us
/ip hotspot walled-garden
add disabled=yes add dst-host=www.thinkdifferent.us
/ip hotspot walled-garden
add disabled=yes add dst-host=*.apple.com.edgekey.net
/ip hotspot walled-garden
add disabled=yes add dst-host=*.akamaiedge.net
/ip hotspot walled-garden
add disabled=yes add dst-host=*.akamaitechnologies.com

We hope that helps for now.

But please if anyone out there has a better solution, do share it with the community.

Best Regards

A different solution was found that does not involve listing the known Apple sites. The credit goes to Matthias Strubel of Wiesbaden in Germany.

It makes use of the User Agent (UA) data transmitted by the iOS7 device.

A typical string looks like: CaptiveNetworkSupport-277 wispr

The URL requested will change, the site requested will change, and number after the hyphen will change, but the device always identifies as CaptiveNetworkSupport to the website.

It appears that the Apple site will respond to this with success.html regardless of URL or which Apple site is chosen from the list.

The solution is to send the device a locally served success.html page if the requesting UA contains CaptiveNetworkSupport. Historically this page has lived at apple.com in the path /library/test/success.html. It can also be seen at captive.apple.com.

I do not yet have Mikrotik equipment. I have tested this solution with the Lighttpd web server and confirmed that it works. I would hope that someone could develop a similar configuration for Mikrotik and openly publish the settings.

We are actually making full use of the captive portal helpers built into as many of the different O/S as possible to fight the issue with Apple etc now using Google as the embedded search (and search being an SSL site now).

Our support calls dropped by around 300 per month once we removed apple.com from the walled garden.

Are they really causing you that many problems?

Hi Guys, has anyone developed a work around for this ?

I have seen an increase in iOS7 users (only) having trouble connecting and the simple bypass technique does not work anymore.

Ideally I would like to utilise the full features of the apple captive portal helpers and not need to implement bypass.

Any advice / code on how to modify the MikroTik hotspot / firewall / system to accommodate would be very much appreciated.

A different solution was found that does not involve listing the known Apple sites. The credit goes to Matthias Strubel of Wiesbaden in Germany.

It makes use of the User Agent (UA) data transmitted by the iOS7 device.

A typical string looks like: CaptiveNetworkSupport-277 wispr

The URL requested will change, the site requested will change, and number after the hyphen will change, but the device always identifies as CaptiveNetworkSupport to the website.

It appears that the Apple site will respond to this with success.html regardless of URL or which Apple site is chosen from the list.

The solution is to send the device a locally served success.html page if the requesting UA contains CaptiveNetworkSupport. Historically this page has lived at apple.com in the path /library/test/success.html. It can also be seen at captive.apple.com.

I do not yet have Mikrotik equipment. I have tested this solution with the Lighttpd web server and confirmed that it works. I would hope that someone could develop a similar configuration for Mikrotik and openly publish the settings.

Similarly to this, I tried to implement this workaround with a firewall layer 7 rule, but no success.
The regexp is "user-agent: (captivenetworksupport|server-bag)" but I cannot find how to apply it.
The idea is to let bypass the hotspot authentication when a packet matches this string (on tcp/80).
Is it possible until there is a proper hotspot code compatible with CNS/CNA ?

We had a the same trouble on a RB1200 5.26 in a hotel.

Windows, Android were able to connect but Not IOS 7.x.x nor MacOS

We found that on mac os, the hotpost.local did not resolve.

After many gess, I found that it was a dns resolution problem.

Ping hotspot.local worked on android, windows, linux but did NOT worked on MacOS nor IOS 7.x.x
Ping www.hotspot.local works for every platform.

The trick was to rename the dns name of the hotspot login page web server from hotspot.local to www.hotspot.local
IP -> hotspot -> Server profile -> DNS name -> [ http://www.hotspot.local ]

It seems that new IOS and MacOS are using MDNS responder in place of DNS request while searching for the IP of hotspot.local

Now safari is able to correctly be redirected to the login web page and IOS 7 device are authenticated.

I also added things in the walled garden
and for the hotspot profile

I think we should mount a joint effort to get Apple IOS fixed. Why is it that Cisco, Mikrotik and other all need to change their code when it is Apple who screwed it up?

Please try this solution we have now posted in the manual: http://wiki.mikrotik.com/wiki/Manual:Cu ... r_override
Let us know if this solves it

Operations with HTTP headers have been supported since RouterOS v5.12, there are other things you can do as well.

It doesn't work...... this user-agent == CaptiveNetworkSupport Nerver comes

I did

$(if user-agent == CaptiveNetworkSupport)

redirect pag1
$(else)
redirect pag2

$(endif)

in all devices redirects to pag2


Thank's

It doesn't work...... this user-agent == CaptiveNetworkSupport Nerver comes

I did

$(if user-agent == CaptiveNetworkSupport)

redirect pag1
$(else)
redirect pag2

$(endif)

in all devices redirects to pag2


Thank's

you do have iOS7 on the iPhone, yes?

Yes i have two IPHONEs one with IOS 7.0 second with IOS 7.0.4

I was tryiing to get it working with the link-redirect but i don't know how to use a variable on mikrotik.

My idea is (because i want to popup ONCE the iPhone window to tell user go to safari)--> i've seen it in other hotspots (don't know captive portal software)

rlogin.html
if mivap="" redirect normaly (to my_php.php (ip opened on garden) post link-redirect)

my_php.php
if link-redirect is one of uses iphon 6 or 7 (http://www.itools.info,www.thinkdifferent.us,www.airport.us.....)
CHANG SOME HOW MIKROTIK VAR (username, error ....) username='CAPTIVE'
and redirect to a new php

iphon will check again connection so rlogin now with this variable will know that is iPhone
rlogin.html
if myvar="CAPTIVE" <HTML>success.........

maybe in login the same

at this momento iPhone will think is with intenet and the Windows popus iPhone (that have to apears to let know the user to log someow) wil change to OK press ok and you can browse safari.

I tried but don't know how to chage VARS

Here is the user agent that needs to be used, did you copy, or write by hand? Maybe try the full line from below, with or without the wispr

Hi,
is not working trying all the convinations with "" with '' with /1.0 with //1.0 ....

But is not getting any difference.
If I write only the HTML code with Success then the CNA is not opening.

I've seen with openWRT the next behavior that i think is the BEST solution.

1) Connects WIFI
2) Open CNA
3) (Some work with php, HTML ¿?¿?) CNA thinks the wifi has internet and change CANCEL link on top right to GO link
Then you insert a message telling OPEN YOUR BROWSER to GET TO INTERNET or some link to any page and
then redirects with BROWSER to the captive portal.

We should try to get it with mikrotik .. i've been trying lots of things but I can't get it.

I have the same issue, I have added the override in rlogin.html, but that does not solve the problem

Hi,
still not success with the cna.
I've tryied on rlogin.html and login.html this:
$(if user-agent == CaptiveNetworkSupport)
<HTML><HEAD><TITLE>Success1</TITLE></HEAD><BODY>Success1-$(user-agent)</BODY></HTML>
$(elif user-agent == Mozilla)
<HTML><HEAD><TITLE>Success2</TITLE></HEAD><BODY>Success2-$(user-agent)</BODY></HTML>
$(else)
<HTML><HEAD><TITLE>Success3</TITLE></HEAD><BODY>Success3-$(user-agent)</BODY></HTML>
$(endif)

Always return Success2-Mozilla. Even with CNA and safari (you can get safari cancelling CNA manually and select Use without internet)

So please mikrotik give us a solutions to let iPhone show the CNA and then return success or wherever to make belive CNA you reach internet and change cancel button to OK.

Thanks

Good day,

I see alot of problems with this also, has anyone tested to see if there is a solutions that has been solved for this?

I have the same issue, the trick code is not working for me.
Mikrotik can you please give me an update about this problem?

$(if user-agent == CaptiveNetworkSupport)
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
$(else)
---- regular content of rlogin.html page ----
$(endif)

Any addvance ?

Just want to know if there is any work arround CNA.

What I'd like is not to add Apple* URLS to avoid CNA.

What I'd like is hotspot -> REDIRECT myPHP --> Detect CNA whait return success and then it will
change to OK CNA button.

Pleas !

We are actually making full use of the captive portal helpers built into as many of the different O/S as possible to fight the issue with Apple etc now using Google as the embedded search (and search being an SSL site now).

Our support calls dropped by around 300 per month once we removed apple.com from the walled garden.

Are they really causing you that many problems?

I am interested in how you approached this with a secured WiFi connection. I would be willing to hire you on if required.

IOS 8 ..... the shit has just hit the fan...
I emailed mikrotik support but they have not solved my problem yet.

The whitelist and walled that we did for ios 7 does not work with ios 8...


HHHEEELLLPPPPPP

It looks like the newest iOS versions use a randomly assigned CNA user-agent number too.
I'm not sure exactly what language the MikroTik hotspot content is using but would it be possible to modify the line to allow a numerical version on the end?

iOS8 no longer need this, since the popup login page supports all Safari features, including video and whatnot. Since this was the only reason to detect the popup, I don't understand what you are trying to achieve?

Simply let the iOS show the user the login page, so he can log in.

Normis,
IOS 7/8 CNA is not like safari.
No javascript, no cookies ....
I've been trying with all of you: mikrotik supporters find a solution to handle this and you don't even try to understand us and give us the solution we need. We still buying mikroitk but not really happy with your help.


Thanks anyway.

Hi

I also having problems with Apple devices.
It seems there in not much problems with Iphone, ipad etc but more with Mac books.
They get the login page but after they logged in the internet works very slow.

After changing the DNS at some Macbooks too 8.8.8.8 they work fine.
But it would be better that it works right from the start and the user have no need to change something at his setting.

Further are we having now a list of things we can do about the apple problems.
I see only part to solve it but not a complete solution.

Can Mikrotik help us.

p.s. Apple is a major problem for us at the moment and i want to get it fixxit

Michel

Has this issue ever been resolved?

I need to have Javascript running for Social login.

Thanks.

Hi,
I just add *success* to the Walled Garden entry Path field

We had a the same trouble on a RB1200 5.26 in a hotel.

Windows, Android were able to connect but Not IOS 7.x.x nor MacOS

We found that on mac os, the hotpost.local did not resolve.

After many gess, I found that it was a dns resolution problem.

Ping hotspot.local worked on android, windows, linux but did NOT worked on MacOS nor IOS 7.x.x
Ping www.hotspot.local works for every platform.

The trick was to rename the dns name of the hotspot login page web server from hotspot.local to www.hotspot.local
IP -> hotspot -> Server profile -> DNS name -> [ http://www.hotspot.local ]

It seems that new IOS and MacOS are using MDNS responder in place of DNS request while searching for the IP of hotspot.local

Now safari is able to correctly be redirected to the login web page and IOS 7 device are authenticated.

I also added things in the walled garden

Code: Select all

[admin@MikroTik] > ip hotspot walled-garden export                
# nov/08/2013 11:14:15 by RouterOS 5.26
# software id = EH11-RCFX
#
/ip hotspot walled-garden
add action=allow comment="place hotspot rules here" disabled=yes dst-port=""
add action=allow disabled=no dst-host=*.apple.com dst-port=""
add action=allow disabled=no dst-host=*.apple.com.edgekey.net dst-port=""
add action=allow disabled=no dst-host=*.akamaiedge.net dst-port=""
add action=allow disabled=no dst-host=*.akamaitechnologies.com dst-port=""
/ip hotspot walled-garden ip
add action=accept disabled=no dst-host=captive.apple.com
add action=accept disabled=no dst-host=www.appleiphonecell.com
add action=accept disabled=no dst-host=www.itools.info
add action=accept disabled=no dst-host=www.ibook.info
add action=accept disabled=no dst-host=www.airport.us
add action=accept disabled=no dst-host=www.thinkdifferent.us
add action=accept disabled=no dst-host=static.ess.apple.com
add action=accept disabled=no dst-host=init-p01md.apple.com
add action=accept disabled=no dst-host=ess.apple.com
add action=accept disabled=no dst-host=apple.com
add action=accept disabled=no dst-host=gps.apple.com
[admin@MikroTik] > 

and for the hotspot profile

Code: Select all

/ip hotspot profile
set [ find default=yes ] dns-name="" hotspot-address=0.0.0.0 html-directory=hotspot http-cookie-lifetime=3d http-proxy=0.0.0.0:0 login-by=cookie,http-chap name=default rate-limit="" smtp-server=0.0.0.0 split-user-domain=no use-radius=no
add dns-name=www.hotspot.local hotspot-address=172.17.2.1 html-directory=hotspot http-cookie-lifetime=2h http-proxy=0.0.0.0:0 login-by=cookie,http-chap name=hsprof1 nas-port-type=wireless-802.11 radius-accounting=yes radius-default-domain="" radius-interim-update=received radius-location-id="" radius-location-name="" radius-mac-format=XX:XX:XX:XX:XX:XX rate-limit="" smtp-server=0.0.0.0 split-user-domain=no use-radius=yes

Hi, we are in 2020 now and the IOS hotspot problems still got me crazy...
did u get fixed the IOS problems adding *success* in file path at the Walled Garden???

Hi,
I just add *success* to the Walled Garden entry Path field

We had a the same trouble on a RB1200 5.26 in a hotel.

Windows, Android were able to connect but Not IOS 7.x.x nor MacOS

We found that on mac os, the hotpost.local did not resolve.

After many gess, I found that it was a dns resolution problem.

Ping hotspot.local worked on android, windows, linux but did NOT worked on MacOS nor IOS 7.x.x
Ping www.hotspot.local works for every platform.

The trick was to rename the dns name of the hotspot login page web server from hotspot.local to www.hotspot.local
IP -> hotspot -> Server profile -> DNS name -> [ http://www.hotspot.local ]

It seems that new IOS and MacOS are using MDNS responder in place of DNS request while searching for the IP of hotspot.local

Now safari is able to correctly be redirected to the login web page and IOS 7 device are authenticated.

I also added things in the walled garden

Code: Select all

[admin@MikroTik] > ip hotspot walled-garden export                
# nov/08/2013 11:14:15 by RouterOS 5.26
# software id = EH11-RCFX
#
/ip hotspot walled-garden
add action=allow comment="place hotspot rules here" disabled=yes dst-port=""
add action=allow disabled=no dst-host=*.apple.com dst-port=""
add action=allow disabled=no dst-host=*.apple.com.edgekey.net dst-port=""
add action=allow disabled=no dst-host=*.akamaiedge.net dst-port=""
add action=allow disabled=no dst-host=*.akamaitechnologies.com dst-port=""
/ip hotspot walled-garden ip
add action=accept disabled=no dst-host=captive.apple.com
add action=accept disabled=no dst-host=www.appleiphonecell.com
add action=accept disabled=no dst-host=www.itools.info
add action=accept disabled=no dst-host=www.ibook.info
add action=accept disabled=no dst-host=www.airport.us
add action=accept disabled=no dst-host=www.thinkdifferent.us
add action=accept disabled=no dst-host=static.ess.apple.com
add action=accept disabled=no dst-host=init-p01md.apple.com
add action=accept disabled=no dst-host=ess.apple.com
add action=accept disabled=no dst-host=apple.com
add action=accept disabled=no dst-host=gps.apple.com
[admin@MikroTik] > 

and for the hotspot profile

Code: Select all

/ip hotspot profile
set [ find default=yes ] dns-name="" hotspot-address=0.0.0.0 html-directory=hotspot http-cookie-lifetime=3d http-proxy=0.0.0.0:0 login-by=cookie,http-chap name=default rate-limit="" smtp-server=0.0.0.0 split-user-domain=no use-radius=no
add dns-name=www.hotspot.local hotspot-address=172.17.2.1 html-directory=hotspot http-cookie-lifetime=2h http-proxy=0.0.0.0:0 login-by=cookie,http-chap name=hsprof1 nas-port-type=wireless-802.11 radius-accounting=yes radius-default-domain="" radius-interim-update=received radius-location-id="" radius-location-name="" radius-mac-format=XX:XX:XX:XX:XX:XX rate-limit="" smtp-server=0.0.0.0 split-user-domain=no use-radius=yes