captive portal is not working on mobiles

Gertjan

@EDaleH said in captive portal is not working on mobiles:

Once you setup your extra portals, I think you will find that the "portal.bhf.tld" is pointing at an IP in DNS that is unique to the DHCP assigned to the first captive portal zone. Port 8003 is the https port for that zone only, it won't work on other zones, they have their own unique ports.

Thus, you will need portal2.bhf.tld pointing at the IP of the DHCP lease for the second zone, say zone2, and captive portal will provide the https login page on 8005, etc for other portals. your "user-portal-url" becomes 'user-portal-url' => "https://portal2.bhf.tld:8005/index.php?zone=$cpzone". You can only leave the zone=$cpzone in place because it will correctly resolve based on the session ID but it will change from zone1 to zone2 for the URL.

My "portal.bhf.tld" is hard coded in my rfc8190.php above.
It's already gone in the file I'm using right now.
The URL used to access the portal contains the &zone=ZONEINDICATOR parameter.
With that info, server IP (the portal base network) is known, so is the host name, like "portalX.bhf.tld".

So everything can be generated on the fly, on demand.

@EDaleH said in captive portal is not working on mobiles:

Android 14 Samsung phone and did a quick test. It supports DHCP 114

Good news.
Apple will probably follow very soon. Maybe the upcoming 17.4 'dev' version, we'll see.
That is, I hope.

@EDaleH said in captive portal is not working on mobiles:

iOS as of 17 still does not support Venu

It does, the venu URL is there, see the image in my previous post, but to hidden to be actually usefull for the average wifi (portal) user.

EDaleH

@Gertjan

@Gertjan said in captive portal is not working on mobiles:

I've found it on the profile page on my iPhone device :

I missed it because I think of that page as the "info" page (but it is a profile) due to the i inside the circle that launches it.
Now that I know where they link it, I think that is easy to add to the handout so thanks for finding it.

For others reading this: on Apple iOS, Settings, WiFi, connect to the portal, click the i with the circle around it,
Because of the DHCP option 114 code/data sent, there will now be a section called "Portal" where it will say:
"This network provides a portal webpage at subdomain.domain.com (for example).
This is the venue link uploaded in the json data file by DHCP option 114, but in this discussion we are pointing it at the "custom" page associated with Services, Captive Portal, click pencil to edit your portal, HTML Page Contents, portal page contents.

If we usee the captive portal logon page link; if the session is already authenticated/active, captive portal (through index.php) will launch the logout page you upload under Logout page contents section for the captive portal.

In our case, we use that logout page to display user id, remaining time & data quota as applicable. Ours is NOT a popup window.

Windows does leave the logout tab open when you connect but once closed you need the url to get it open again. For windows users, publishing the url in a handout/email is the only way for them to return to the "logout" page. As this is the least common denominator, that published URL will work in a browser tab on Windows, Android and iOS devices so the venue url utility is diminished in terms of usefulness. Individual device users may prefer the Android Notification or iOS info/profile link so it is wise to implement it through DHCP 114 for their convenience.

@Gertjan said in captive portal is not working on mobiles:

My "portal.bhf.tld" is hard coded in my rfc8190.php above.
It's already gone in the file I'm using right now.
The URL used to access the portal contains the &zone=ZONEINDICATOR parameter.
With that info, server IP (the portal base network) is known, so is the host name, like "portalX.bhf.tld".

So everything can be generated on the fly, on demand.

I am not sure I agree, hopefully I am not missing something here?
What we know is the IP of the device ($clientip = $_SERVER['REMOTE_ADDR'];), not the URL. Normally Captive Portal generates the url that executes index.php but with DHCP 114, there is no "capture" per-se; captive portal is not yet involved so we would have to connect to the URL directly as if the end user typed it in, rather than the rule based process that captures the http:// port 80 request and then creates that url for us. This means we must construct the login URL in advance of sending the json data file to the device through DHCP option 114 so the device's temporary browser can call it directly on an SSL/TLS port. To construct that URL we need to know:

The subdomain of the certificate: "portal" in your example. We know each portal has a different subdomain so that it can be associated with the unique DHCP pool of the specific captive portal.
The domain of the certificate: This is typically/likely the same for all captive portals: "bhf.tld" in your example.
The port this portal is on. Although the rfc8910.php code is trying to resolve the zone, I don't think we can determine which portal it is associated with so here we have to hard code it. 8003 for the first, 8005 for the second, etc, etc.
4 The zone: in this case we can determine that from the $cpcfg array.

All of the above information is (can be) in the URL coded into the DHCP option 114 so I think we should be able to parse the URL that called us and by doing so, make a single, universal, rfc8910.php file. I will look into that and post back here if I succeed. I am still not convinced that a file per captive portal is not easier to administer but a universal solution is better if we look at it from the user community perspective. If we succeed, then it could even become part of the project or a patch.

I also want to point out, to those not using multiple portals yet; that you need a Level 2 switch on OPT1(tagged)/LAN(untagged) that supports the VLans (one fore each captive portal), or separate network cards, to implement multiple captive portals. Each portal is assigned to a separate interface in System, Captive Portal, Portal Name. Once that is done, it is easy to construct (hard code) the URL because pfSense/Captive Portal never intercept the URL, the temporary browser goes directly to executing index.php through the URL provided in the json data file sent by the DHCP option 114 which is executing the suggested rfc8910.php file through the "temporary" browser prior to anything being captive, it is done at the time of assigning the client IP when initially connecting to the network.

EDaleH

This post is deleted!

EDaleH

This post is deleted!

EDaleH

@EDaleH

I modified your rfc8910.php to parse the url passed from the DHCP option 114 string such that it launches the correct login URL for each portal through the json data string without any additional files required. It is universal as long as the string placed in the DHCP option 114 server contains the subdomain.domain.com:port info. I checked it on 6 portals with voucher, user and freeRadius authentication. If keeping things clean is an objective, this approach is a one file solution to all DHCP option 114 RFC8910 syntax for user and venue options.

Note that I commented out the seconds_remaining code as it was throwing an exception on my portals authenticated by freeRadius. I did not debug that further.

RFC8910-parse url.txt

EDaleH

@EDaleH

Note: the Apple example has the json URL links inside double quotes as a string. In the above code that would suggest => "$rfc8910_url", not just => $rfc8910_url. In testing it worked equally well both ways.

Gertjan

@EDaleH

$rfc8910_url = 'https://' . $_SERVER['HTTP_HOST'] . '/index.php?zone=' . $cpzone;
....
		"user-portal-url" => $rfc8910_url,
		"venue-info-url" => $rfc8910_url,

Ok .... you've found the fun part It was one line.
All reduced to a bare minimum.
I've also ditched the 'remaining time' lines, and use you version right now.
I still have to find a spare AP so I can spin of a second portal, but since you've tested it on 6 portals, you've got me already convinced.

@EDaleH said in captive portal is not working on mobiles:

or a patch

Exact.
Now it's just one stand alone file, and for every portal network, the DHCP server needs an 'option 114' correctly set up, so ISC-DHCP is needed, not KEA.
It's very close to a click-and-play addition.

So, very nice that this works. Last question : what are the side effects that we haven't discovered ?

EDaleH

@Gertjan said in captive portal is not working on mobiles:

I still have to find a spare AP so I can spin of a second portal

Check if your AP runs OpenWRT (https://openwrt.org/toh/start), it supports multiple VLans and StationIDs. I use an Archer C7 in the Lab and have 14 separate Captive Portals on it which are on two separate pfSense configurations simultaneously. I paid $20 CDN for it on Facebook Marketplace. You will need a simple level 2 managed switch, I bought a $35 CDN 8 port TP-Link unit (TL-SG108E) on Amazon and you will need to configure WAN, Lan, Opt1 network interfaces to support the setup of the VLans required for each Captive Portal. You needed a new project anyway, didn't you? FYI, I also use DHCP 114 on the DNS for a different OpenWrt Router setup as a hotspot on a pfSense Network. It loads the "logout" page through the index.php link on pfSense and will load on any device connected to the Hotspot. This provides service to individual, self contained, sites where they use it for local WIFI access and we control bandwidth/time/data quota through the single pfSense freeRadius account that serves them. In this way we distribute the load on pfSense and more important, we have more control over bandwidth/quota/time usage for multiple logins to a single account as pfSense's Captive Portal provides full bandwidth, quota and time to each individual login to a multiple concurrent logins user account. freeRadius does not suffer from the 4096GB limit issue so custom code disables that check and uses freeRadius to manage data, with custom code to manage time within captiveportal.inc. Most have 500 GB to 1 TB data limits per month and ran flawlessly in 2023. see Redmines 13843, 13844 for more info.

Gertjan

@EDaleH said in captive portal is not working on mobiles:

Check if your AP runs OpenWRT

They do....

I've 4 of these in the building.
Rather ancient
I'm not using any VLAN stuf, as I have a SG4100, so LAN ports enough.
A year or so I bought a TL-SG108E to 'play' with, but that never happened.

I'm using the pfSense FreeRadius package just for the 'authorization', I'm (normally) not byte counting neither bandwidth limiting (accounting). My AP's limit the connection by themselves already (30 Mbits max).
My main down link/up link is about 1 Gbits/sec, so "the can have it".

EDaleH

@Gertjan

Once the access points are configured for VLan support, each packet will be tagged for a VLAN or not tagged for LAN. It is surprisingly easy to set up, especially if you already have the switch. Configure the appliance for WAN, LAN, OPT1 and put your "tagged" traffic on the OPT1 but specifying VLans, typically vlan1=> tag=10, Vlan2=> tag=20, etc. Then create multiple stationIDs on the access point with one untagged and the remainder associated with a specific tag/VLan. Each will have their own Captive Portal and authentication. Now it just works. If you still have that switch and enough ports to cover your premises, you are up and running. Two ports on the switch are for LAN and OPT1 to the appliance, the rest feed your network. Any additional switch along the way, that is not L2 and programmed, will strip the tags so you want a straight run to the AP to avoid loosing the "VLan tag". You only need worry about the tagged traffic on a network cable if there is a device (i.e. Access Point) that is processing tags, on the others any L1 switch will strip the tags or you connect that switch to your switch through a port on your L2 switch that is "managed" as an untagged port. Your APs may need to update their firmware but possibly not, just see if it has tagging options (VLan) under wireless setup for a station.

If you ever set it up, you will kick yourself for not having done it sooner.

Bisho

Hi,

@EDaleH and @Gertjan. Thank you for your valuable input on this topic.

I've submitted a new related topic https://forum.netgate.com/topic/188402/captive-portal-not-working-on-ios-devices-only-dhcp-114

I would appreciate it if you could have a look. However, here is what I asked if you prefer to keep it on this topic:

I’ve been helping a friend at a hotel set up the pfsense’s Captive Portal. It's working perfectly on PCs and Android devices, but when it comes to iOS devices, the portal page to enter the credentials never shows up.

I’m aware of the iOS’s connection test HTTP request to http://captive.apple.com/hotspot-detect.html , but the problem here is that my friend is located in a country where Apple.com along with some other websites are blocked by the government for unknown reasons. So this site will neither give “Success” nor “Failed” because it’s not even reachable.

I’m hoping for some clear guidance.

1. Is the DHCP 114 option the way to bypass the connection test HTTP request to http://captive.apple.com/hotspot-detect.html ?
2. If yes, what line(s) in Index.php has to be modified or added? Where do we force the iOS device to our desired redirection URL ?
3. If not, what can be done in our particular scenario ?

Thank you,

Gertjan

Moved to here.