ianbmacdonald
commented
1 year ago In a non-inline configuration, Apple clients that captue Option 114 on the Registration network will operate in RFC8908 mode, and then go looking for the API when they arrive on the Normal network.
Since Packetfence presents the API URL with "captive": true all the time, if it can be reached when clients hit the Normal network, they think they are still trapped. This is independant of the traditional network detection used in the captive-portal landing page and independant of the Option 114 presented in the Normal network.
It is also consistent with the RFC language that states, once captive, it should return to the same place to determine when no longer captive.
Once the user satisfies the requirements for external network access, the client SHOULD query the API server again to verify that it is no longer captive.
When the client requests the Captive Portal JSON content after gaining external network access, the server responds with updated JSON contentIt was the work in https://github.com/inverse-inc/packetfence/issues/7040 that implents the API partially, in a static captive form, that is causing this issue. The clients return and think they are still captive, but they are not. And they ignore all other signals.
Simply blocking access to the API fixes the problem, as the client eventually gives up and accepts it is now on a non-captive network, however this means that email activation, or any other portal service can no longer be used on the Normal network.
To get Apple clients behaving in a somewhat normal way, and use Secure Redirect, you have to start Packetfence with Secure Redirect disabled, to prevent Option 114 on the Registration VLAN, and then enable Secure Redirect in the GUI and restart the haproxy and portal services. This seems to work on PF11 and PF12 so far, but does not allow for a server restart without manual intervention due to the inability to control Option 114.
Additional Discussion and Context https://sourceforge.net/p/packetfence/mailman/message/37769967/ https://sourceforge.net/p/packetfence/mailman/message/37769965/ https://www.rfc-editor.org/rfc/rfc8908.html
Is your feature request related to a problem? Please describe. iPhones (IOS 15, 16) are using the Option 114 value to swith to RFC8908 mode, and use the API for network detection.
This breaks captive portal detection for these cleints when returning to the Normal network in non-inline configurations of Packetfence.
If option 114 is advertised, the clients will use the API. If it is not advertised, they first check for the traditional captive portal URL. The following debug grabbed from the Apple forum shows this behavior
Attempt 1: com.apple.captive default 12:04:40.051877+0300 configd en0: Probing 'portal2' Attempt 2: com.apple.captive default 12:08:19.191328+0300 configd en0: Evaluating API 'portal2'
If Option 114 is present on Registration, the traditional network detection is ignored on the Normal network.
To workaround these client issues detecting the Normal network, it would be ideal to be able to support the Secure-Redirect feature and also to disable the Option 114 advertisement of the Captive Portal URL which currently reference the rfc7710 API endpoint.
Blocking the portal API URL on the Normal network works around the issue, as the client will give up on the API, but is not an option if you require it for activation from the Normal network in a link sent by email.
Describe the solution you'd like A cli option would be sufficient for disabling Option114, as it seems likely this problem will probably go away with progress on increased support for existing captive portal RFCs using the API
Describe alternatives you've considered Running with secure-redirect disabled to start up packetfence, then enabling the feature in the GUI, restarting portal services, which allows current v12.1 to operate with Secure-Redirect enabled, but without the DHCP Option 114; At least until the next server restart, which then reverts to including Option 114 when the Secure-Redirect is enabled.
We also tried various Option 114 options on the Normal network, with no luck, including
The iPhone just ignores it from as far as we can tell.
Additional context https://developer.apple.com/forums/thread/660827 https://github.com/inverse-inc/packetfence/issues/5638 https://github.com/inverse-inc/packetfence/issues/7040 https://developer.apple.com/news/?id=q78sq5rv