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 >
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
