[PacketFence-users] iPhones trapped on reload of Captive Portal Log In Page after switch to Default network

[Ian M. <im...@ne...>]

Okay,

We have, again, scoped down our issue further to iPhones not properly
detecting they are no longer behind the Packetfence Captive Portal.  I am
going to frame it up once again to see if anyone has any new insights.

Problem:  The iPhone is holding on to the captive portal page it learns on
the Registration network, and when it gets to the Default network, it fails
at detecting it is on the Internet, and it returns to the Captive Portal
page and traps the user there in the iphone's Log In interface.

If we block the iPhone from the Packetfence portal listener, after it is on
the Default network, it works and believes it is no longer Captive.
Unfortunately this also blocks registration activation links sent via
Email, so it doesn't quite qualify as a workaround unless we can separate
the hostname used for Email Activation from the hostname used for the
Captive Portal and block the latter with DNS overrides on our Default
network.

It seems like the correct configuration would have Packetfence instruct the
iPhones to not use the Captive Portal URL reachability as network
detection, and possibly we have no control over this OR possibly it can be
done somehow through the Captive Portal API TBD.

Help on how to do either of these things in Packetfence config appreciated.

Here is our lab v12.1 setup.

[image: image.png]
As we moved through our testing we have made a few changes, none of which
seem to impact the expected outcome.  We have enabled proxy interception,
changed our network detection to a local IP,  modified the detection delay
(30s) so that it starts after the fencing delay (25s), and allow 60s for
the re-evaluation on the portal page progress bar.   We disabled CSP
headers and secure_redirect in hopes of providing more information during
packet captures. Passthrough during fencing is now disabled as well to keep
traffic to a minimum.  Our registration DHCP lease time was shortened to 15
seconds.

[fencing]
wait_for_redirect=25
interception_proxy=enabled
[captive_portal]
network_detection_ip=104.244.196.157
network_detection_initial_delay=30s
network_redirect_delay=60s
request_timeout=5
secure_redirect=disabled
rate_limiting=disabled
[advanced]
portal_csp_security_headers=disabled

[10.2.2.0]
dhcp_default_lease_time=15
dhcp_max_lease_time=15

The iPhone in this latest scenario is an iPhone 7 Pro running IOS 15.
Registration has no issues, and VLAN switching occurs as expected at 25s on
the "Enabling network access" portal page, placing the iPhone onto the
Default network.

[image: image.png]

When the iPhone is disconnected from the Registration network, the Log In
page closes, and the wifi settings appear briefly.

[image: image.png]

The iPhone then connects to the Default network, however it decides it must
be still behind the packetfence captive portal, as it reloads the Portal
Login page again, and the user is trapped, and can not escape except to hit
Cancel and select "Use without Internet".

[image: image.png]

*The iPhone is holding on to the captive portal page it learned on the
Registration network, and when it gets to the Default network it fails at
detecting it is on the Internet, it returns to the Captive Portal page, and
is effectively trapped there.  If it can see the Packetfence listener, it
believes it is still captured.*

With this in mind, we decided to simply block traffic from the Default
network to the Portal Page with a simple firewall rule to drop traffic to
the packetfence public IP.

And the iPhone detects Internet.  That was it.  The detection was not based
on DHCP option 114, or reaching some other site, or
the network-access-detection.gif  It is based on reaching the Captive
Portal URL, which is responding, as it is the same hostname where we expect
our users to go for Email Activation Links.

The problem with blocking the Portal listener on the Default network is
that the user can not complete the email registration, as the same portal
listener that serves up the Captive Portal service up the Registration
Activation Link (/activation/email.html).

It suggests we have to get the iPhone to ignore the Captive Portal URL it
learned from the Registration VLAN?  Is this a bug in implementation of the
captive portal API usage in iPhones?

Our Default network DHCP  sees Option 114 requested, and provides the
unrestricted value (shown below).  Maybe somebody can confirm the format
and content is correct so we can validate our assumption that the iPhone is
just ignoring it.  We also pass the same value in Option 160 just in case
it ever is requested by an old client.

[image: image.png]

I have collected pCaps from the Registration VLAN (Interface 10.2.2.2 on
our PF server) and from the Default Network (Interface 10.2.4.1) as well as
the haproxy_portal.log and packetfence.log from the same time period.
 Nothing removed from those time periods, as there were no other devices on
those networks.   I will leave them up whilst we are working on this issue
for anyone to inspect with Wireshark.

https://drive.google.com/drive/folders/1NFuDqJIkPrsMWs_DXqIeY0l_TTLYkPpE?usp=share_link


I suppose a workaround could be to change the [% activation_uri %] to a DNS
hostname alias that is different than the captive portal hostname and
override the Default Network DNS so that the captive portal URL goes
nowhere (equivalent to our firewall block),  allowing the users to still
hit the activation link and block iPhones from getting trapped on the
portal page at the same time.

A follow-up question is does anyone know how to specify the activation URL
as a configuration parameter?  We couldn't find it, as it seems generated
in the templates.

It seems we are just down to configuration here;  Getting close.