Hi Ian Regarding error "Your computer was not found in the database"
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 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. Enrique 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
