Hi Enrique,
> Regarding error "Your computer was not found in the database" > This is presented to anyone hitting the portal from the public Internet. For instance if you went to http://pf4.dotto-one.com/ right now, you should see it, as the listener is active, for other client activities like email link activation, pre-registration (we do not use) and the default captive portal landing page will not find you in the database, because it can only do MAC based identification on the registration and isolation networks where it can see that L2 information. Traffic from the Internet is routed, and will show as MAC:0 and the current client public IP at the bottom of the page. On the iPhone, once network detection is complete, it shouldn't be talking the user back to the captive portal, but it is. Just blocking this traffic would force the client into believing it was no longer captive, but this would prevent access to the listener for email activation. > Have you tried local DNS resolution for the captive portal domain on > the default network, applying firewall rule to secure access to the > portal listener interface > I am not sure what you are asking me here. The DNS server on the Default network is on the local subnet, and is the gateway. It resolves the same public DNS as the link above to the portal listener. The firewall in front of the portal listener has firewall rules, and only Port 80/444 are allowed and forwarded on to the packetfence server portal listener. I believe this is standard routed topology; It has been setup this way since our first routed captive portal on Packetfence 5. - And I'll throw this unrelated comment in. ** We only use the captive portal functionality for free public wifi; though I am keen to find some clients that need a full NAC. The fact that we have been able to evergreen some circa Packetfence 5/7 instances across Debian upgrades is impressive and speaks to the Inverse team's platform commitment. The new docker model reduces cross-platform complexity even further. The GUI is so functional; In my recent sessions, I stumbled across the netflow renderings; The lease timelines; It is sharp; Bien fait. I posted modified hostapd.sh <https://github.com/inverse-inc/packetfence/issues/7472> for recent OpenWRT releases which will hopefully show up in Add-ons. It makes it straightforward to turn any supported OpenWRT hardware into a captive portal for anyone wanting to get familiar with Packetfence, radius, vlan switching, isolation, authentication, etc. without any enterprise gear in their home lab. ** > > When the client lands on the default network, resolving the external > IP address for the captive portal domain, that "Nating" presents “as > computer not found on database”, I remember also adding a "network" > filter to the connection profile for routed networks that need to > access captive-portal. > I am not sure I understand what you are suggesting; The "computer not found on database" is the expected result - we just do not want iPhones getting there once they are connected to the Internet. They should just detect Internet and move on without returning to the portal. If we block it using the firewall, detection is fine. If you know how to create a filter for the /captive-portal on the public facing portal listener, that would be one way to workaround our iPhone network detection problem. All our other clients that we have tested seem to be okay with the current javascript implementation. We just need to get the iPhones fixed until RFC8908 is supported. I can see it has been discussed <https://github.com/inverse-inc/packetfence/issues/7040> but it seems what used to work in IOS 13/14 using the RFC7710bis <https://github.com/inverse-inc/packetfence/issues/5638> introduced in PF10 isn't working any longer. The clients do not use the network detection IP or image embedded in the captive portal javascript as seen in the captures we posted. They simply 'test' if they are still trapped based on reachability to the captive portal URL. I believe if we can somehow separate the ConfNet.PortalFQDN used by the captive portal redirect from the one used in email activation, we can use our Default network local DNS to make the current RFC7710bis implementation work with iPhones. If you know how this could be done, it would be a second to workaround our iPhone network detection problem. > El mar, 24 ene 2023 a las 19:59, Ian MacDonald (<i...@netstatz.com>) > escribió: > > > > Quick inline response to your questions; Thank you for having a peek. > > > > On Tue, Jan 24, 2023 at 5:45 PM Enrique Gross via PacketFence-users < > packetfence-users@lists.sourceforge.net> wrote: > >> > >> Regarding DNS, domain resolves to your public address? is that > >> correct? And that is the same domain as captive portal? > > > > Yes, as seen from the Default network, and the Internet, the packetfence > server hostname resolves using public DNS, and lands on the portal listener > attached to the management network interface on the server. > > > >> > >> On your topology, port 80/443 redirected to “PF redirection URL”? > > > > > > Yes, in hindsight, that detail should have been removed, as it is > confusing in that it is unrelated to the issue, and that redirection rule > is not active in this test environment. > > > > In production, there was a redirection URL in the Captive Portal > configuration that goes to a web site; Provided by the ISP that is > providing the free Internet. > > A similar redirection, if you happen to point your web browser at the > Default network gateway, also goes to that same location. The thinking > here was if you are surfing in the Public space, and get curious and do a > myipaddress.com look up and then go to that IP in your browser, you hit > the same landing page as the captive portal redirection. > > > > It is not active in this environment, so I should have purged it from > the topology snapshot > > > >> > >> 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 > > > > -- > > > _______________________________________________ > 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
