Hi Ian. Dont worry!, good luck on that!
Enrique. El jue, 26 ene 2023 a las 13:25, Ian MacDonald (<i...@netstatz.com>) escribió: > Enrique, > > >> If you need to access portal services from the default network, i think >> you don't really need to resolve pf4.dotto-one.com to your public >> address, you can add a static record on your DNS server on your default >> network, pointing pf4.dotto-one.com to your local captive-portal >> listener address, then config your router/firewall so you can reach portal >> listener address from the default network. >> > > Not sure I understand. I believe when you say "local" you mean on the > same subnet and router/firewall you mean the gateway for the > default/production network. This is not an inline configuration, so there > is no captive portal listener on the default/production network. > >> >> I'm not really sure this is the "right" way to configure this, but I >> manage to access portal services this way from routed networks, changing >> connection profile filter. I had to do this to access self-service >> registration from a remote network. >> >> [image: imagen.png] >> > > This looks like the set of variables from your connection profile to match > clients to a specific profile. I believe the Basic filters are just OR > operations. I am not really understanding how this relates to the iPhone > network detection issue we are trying to resolve. We have no issues with > client association to the correct networks; These evaluations for devices > on the Registration networks do not apply once devices are out on the > Production network, where our network detection issues apply. Packetfence > can not identify the MAC on Production networks in non-inline setups, > without pushing data back via DHCP connectors or otherwise. > > Also, once a client lands on the default network there is no need to >> access the portal, as registration is done, and the client is placed on the >> desired VLAN. >> > > I think you misunderstand our Captive Portal configuration, where clients > are granted only a few minutes of access, after which, if they do not click > the Activation link sent from the Packetfence server, they are booted back > to the Registration network. > > The activation link points directly to the portal listener page with a > client specific URL to both complete the registration for a longer access > period and display that information back to the client. > > >> *But if client lands on the default vlan and gets new DNS server from >> DHCP maybe will still intend to resolve pf4.dotto-one.com >> <http://pf4.dotto-one.com> again hitting the "Your computer was not found >> on database"* >> > > Yes, the portal needs to be resolvable from the Production network in > order to use the Activation Link sent by email; Maybe for other reasons > too; We do not use like the Status page, and re-registration functions. > Like most things with PF, there is amost and endless amount of > configuration variations hooking into the various endpoints available. > > >> I understand that when RADIUS disconnect is done, the client reconnects, >> gets a new VLAN, new IP and maybe a new DNS server. *What happen next is >> that client should be redirected to the "Redirection URL"* >> > > The redirection URL, which is passed to the client isn't always obeyed or > followed; It is very client specific. But yes, after network detection, > if the client can handle the redirection, it will execute it. For clients > that persist the network evaluation across the network change, when they > get to the end of the progress bar, generally the redirection works as they > are following the javacript page and its embedded functions exclusively. > On clients that close portal capture on network changes (like the iPhones > we are testing) as soon as they detect the network change, they may often > not perfom the redirection. YMMV here. > > >> I'm new to packetfence, i don't want to mislead you on your config, I >> have found your setup interesting and your troubleshooting is super good to >> keep on learning on this. >> > > No problem Enrique. I would say if you have specific questions, fire up > a new thread. > > Even though I only pop up here every few years looking for a bit of help > on keeping this free public service wifi rolling, I am always concious of > keeping a balance between benefiting from free support and giving back to > the community, and helping offload Inverse/Akamai resources that might > otherwise be focused on paid engagements. Through this little iPhone > issue I have found some cycles to report some issues, enhacements and post > contributions. I would encourage anyone to do the same - and although I > believe you might be adding some cruft to my thread to resolve this iPhone > issue - I like that you are trying to jump in and offer some help based on > your own experience. > > Ian > >> >> El mié, 25 ene 2023 a las 11:27, Ian MacDonald (<i...@netstatz.com>) >> escribió: >> >>> 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 >>>> >>> >> >> -- >> >> [image: Imágenes integradas 1] >> _______________________________________________ >> PacketFence-users mailing list >> PacketFence-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/packetfence-users >> > -- [image: Imágenes integradas 1]
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
