Adding context to 114 DHCP Text Value
-
Is there any way to make a DHCP Text Value (specifically option 114) contain an Identifier related to the client request? Something like:
https://externalserver/getTheCaptiveJSON?clientMac=xx:xx:xx:xx...
Because at the moment, I have no idea how to let my auth server know if the captive portal session is valid or not -- iOS just sprays a few get requests to the main endpoint with no context.
I'm attempting to follow Apple's documentation to modernize my captive portal as outlined here: https://developer.apple.com/news/?id=q78sq5rv
I currently have a DHCP 114 Text Value that successfully redirects iOS and Mac clients with the popup safari to the my portal api - where the portal api can then respond with a 'captive: true' or 'captive: false' JSON.
So far the setup is as follows:
- Client -> pFSense 114/Captive Portal -> External Server (get: CaptiveJSON)
- Client -> External Server (do auth stuff)
- External Server now knows 'some' client has done auth stuff
- Client (through iOS) sends another 114 request with no context -> External Server sends back 'Still Captive' json
Since this is an external server, it only sees the forwarded IP address - which doesn't really help me if I have multiple clients trying to connect in succession, nor does it help me track once a client has successfully agreed to my terms of service and other details I must capture for agreement.
Is there any way in pfSense to inject some client id?italicised text
-
@charliemiller008 said in Adding context to 114 DHCP Text Value:
https://developer.apple.com/news/?id=q78sq5rv
It's still a proposed draft RFC.
For years I'm looking also at this Apple page and proposed solution, as it will simply the captive portal a lot.
After a simple DHCP request, the device will know a portal is in play, how to get a login page, status page, help page, etc.
Things would be easier to handle on the pfSense side too.
But support has to be build into the client side. As I use apple devices myself, I've edited scripts the captive portal uses so it prepares this JSON file upon request.
Adding the 114 option to the pfSense DHCP server is easy.
It worked ...If the apple device do not find this DHCP option 114, they fall back to the current portal detection : they send a http://someapplesite.tld and when the word "Success' doesn't come back as an answer, it launches a build-in browser (a stripped down Safari browser), and repeats the http://someapplesite.tld request. The http (not https !!!) request gets redirect to the captive portal web server ..... and pure magic kicks in : the login page shows up.
Using some other server : maybe, never tried that.
Btw : this RFC will also deal with dual stack = IPv4 and IPv6. Still, the captive portal firewall handling will get 'complicated'.
Maybe in pfSense [future] ? ;) -
@gertjan very interesting. Thank you for this.
I was on a few 'premier' captive portals recently - American Airlines/GoGoInflight and a large state university - and I realized that they don't use the 114 option either. It's easy to break the Guest Wifi workflow though with iOS and Mac; just ignore the window the first time. Their Captive Portals don't redirect https either - so you have to know neverssl.com or something similar to get back to the portal.
Returning to the solution and discussion: setting the iOS device to see the 114 option is super easy. However, after I do my auth - the iOS requests again to the url, but now I have no context. I guess this is primarily because the IP address is forwarded from the pFSense. Even if I use Tailscale or Wireguard to get all the devices on the same network - pFSense / Netgate box is forwarding the request, so I can't tell who is coming in based on the iP address, nor mac address.
Am I missing something? After you got the 114 login portal working, how did you redirect the iOS device to a 'captive: false' json? I'm missing that part.
