Hi Ian 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.
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] 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. *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"* 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" * 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. Enrique 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
