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

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

James,

Thanks for having a closer look at this,

>
> So looking through the registration PCAP, one thing I notice is that
> there's three requests for http://captive.apple.com/hotspot-detect.html
> before it tries to follow the redirect that page returns. Also your DNS is
> returning the same IP (66.70.255.147) for captive.apple.com as for
> pf4.dotto-one.com. Are you doing DNS enforcement on the portal? Then on
> the default network, you return 104.244.196.73 for pf4.dotto-one.com. I
> don't think that's wrong per se but just wanted to be clear.
>

Yes, that is correct;  captive.apple.com is intercepted by Packetfence,
which controls the DNS and uses the special IP 66.70.255.147 where it can
put up a legit https response to the captive portal inquiries.


> I see some accesses to https://pf4.dotto-one.com/rfc7710 after it joins
> the default network, can you see what content is returned? Since it tries
> that first before going to the captive portal URL on the default network.
> Short of that, could you remove option 114 and 160 from both registration
> and default network DHCP scopes? My feeling is that it's holding onto the
> URL from the registration network and re-using that on the default network
> instead of looking at the cappport:unrestricted value returned on the
> default network.
>

Yes, the iPhone returns to the captive portal URL, which on the Default
network resolves to the correct and reachable public IP for the portal
server.   We can remove the DHCP option 114,160 from the Default network
scope easily, and that is how we started, so we know that alone will have
no impact.   On the registration network, I am not sure if dhcp_filters is
the way to do this, but I tried and it didn't seem to like my syntax;  I
treid to change the DNS too in order to be able to easily verify the filter
was being applied.  Not sure where to go to figure this out.

[option114]
run_actions=disabled
status=enabled
answer.0=114 =
answer.1=5 = 8.8.4.4
description=No Option 114
scopes=Discover,Request

pf4:/usr/local/pf/conf# vi dhcp_filters.conf
pf4:/usr/local/pf/conf# /usr/local/pf/bin/pfcmd configreload hard
/usr/local/pf/conf/dhcp_filters.conf: option114) Error building rule


> So was the iPhone not re-DHCPing problem solved by very short lease times
> on the registration network?
>

No, I did not change those back until after the captures, so it is 15s
there - you can see it somewhere in the captures.  The registration VLAN
lease time appeared to have no material impact on how the iPhone lands on
the Default network.   The re-DHCPing is now consistent and fast.   The
DHCP server was updated to use the 2-message handshake and it was also
upgraded to the most current DHCP version as well (OpenWRT 22.03.3 vs
21.x)  -  I have not gone backwards to reproduce that slower DHCP response,
as the behavior is now what we expect, so I can not be absolutely certain
it is the faster 2-message handshake.

It is worth noting that now that we have isolated the Default network
detection on iPhone, I have rolled back to almost complete defaults, and
the results are consistently the same.   Blocking the access to the captive
portal URL allows the iPhone, 7, 8, 12 to all perform network detection in
a way that provides the desired user experience.

pf4:/usr/local/pf/conf# cat pf.conf | grep -v "#"| grep -v ^$ | grep -v
pass | grep -v ".com"
[general]
hostname=pf4
send_anonymous_stats=disabled
timezone=America/Toronto
[fencing]
wait_for_redirect=25
[alerting]
[database]
db=pf
user=pf
[captive_portal]
network_detection_ip=104.244.196.157
network_redirect_delay=30s
rate_limiting=disabled
[advanced]
configurator=disabled
openid_attributes=
[interface eth0]
type=management,portal
mask=255.255.255.0
ip=10.2.1.2
[interface eth1]
type=internal
mask=255.255.255.0
ip=10.2.2.2
enforcement=vlan
[interface eth2]
enforcement=vlan
ip=10.2.3.2
mask=255.255.255.0
type=internal

cheers,
Ian

> Thanks,
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
> On 24/1/23 06:53, Ian MacDonald via PacketFence-users wrote:
>
> 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.
>
>
> _______________________________________________
> PacketFence-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/packetfence-users
>
>
> _______________________________________________
> PacketFence-users mailing list
> Pac...@li...
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>