Hi Ian Regarding DNS, domain resolves to your public address? is that correct? And that is the same domain as captive portal?
On your topology, port 80/443 redirected to “PF redirection URL”? Enrique El mar, 24 ene 2023 a las 8:19, James Andrewartha via PacketFence-users (<packetfence-users@lists.sourceforge.net>) escribió: > > Hi Ian, > > 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. > > 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. > > So was the iPhone not re-DHCPing problem solved by very short lease times on > the registration network? > > 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. > > > 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. > > > > When the iPhone is disconnected from the Registration network, the Log In > page closes, and the wifi settings appear briefly. > > > > 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". > > > > 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. > > > > 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 list > PacketFence-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/packetfence-users > > > _______________________________________________ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/packetfence-users -- _______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
