Feature #15321 shows how to use Option 114 in Kea

EDaleH

For those of you, like me that want to try Kea but can't because of the lack of support for RFC8910, option 114 for captive portals, particularly the iPhone, this feature now shows how this can be temporarily accomplished until it is fully supported. Be careful to use the correct interface and check out "captive portal is not working on mobiles" in this topic if you need to know about RFC8910 and DHCP 114 support.

https://redmine.pfsense.org/issues/15321 Patch tested on 24.08 Dev Sep 25

Gertjan

@EDaleH

I couldn't test drive kea mainly because of this. The RFC8910 DHCP 114 option support does wonders for the captive portal.
And since last week I also use the option "43" : (Unifi AP support)

EDaleH

The patch in Feature #15321 also works in 24.11 Oct 31 Beta.

Gertjan

@EDaleH said in Feature #15321 shows how to use Option 114 in Kea:

The patch in Feature #15321 also works in 24.11 Oct 31 Beta.

Thanks for the info.
I've activated kea last friday and all went well.

I've installed the patch from Marcos ( https://redmine.pfsense.org/issues/15321 )

Created my own option JSON content :

{
  "option-def": [
    {
      "space": "dhcp4",
      "name": "custom-option-vendor",
      "code": 43,
      "type": "binary" 
    }
  ],
  "option-data": {
    "opt2": [
      {
        "name": "v4-captive-portal",
        "data": "https://portal.bhf.tld:8003/rfc8910.php?zone=cpzone1" 
      },
      {
        "name": "custom-option-vendor",
        "data": "01 04 C0 A8 01 06" 
      }
    ],
    "lan": [
      {
        "name": "custom-option-vendor",
        "data": "01 04 C0 A8 01 06" 
      }
    ]
  }
}

edit 2024-12-03 : I've changed the "custom-option-vendor" type from String to binary.
And changed the format (==data) from to "01:04:C0:A8:01:06" to "01 04 C0 A8 01 06".
When I was doing a packet inspection using the interface 'opt2", protocol UDP and ports "67 68" I saw the DHCP Option request from the client, and the DHCP server kea option 43 answer (that already great), which had a 'strange' (?) looking sequence like 42 49 52 78 45 ... something like that.
So I decided to have it send out 6 bytes in binary (hex), hoping this works ./ is better.
I might be wrong. Maybe it was just the packet packet inspector showing the data in a strange way, and it was actually working.

end edit.

This : option '43' for my lan and the captive portal (as I have Unifi APs), pointing to 192.168.1.6, the controller.
A captive portal with with rfc8910.php support on interface "opt2" = option "114".
True : option 114 is known to kea, so no 'type def' needed.
I've saved the info on the main Kea settings page, and the captive portal DHCP page.
I've checked the kea config file /usr/local/etc/kea/kea-dhcp4.conf for coherence, it looked good.

And it works
Great work.

Btw :
For those who think that KEA logs to much, change :

			'severity' => config_get_path('kea/loglevel', 'WARN')

for

			'severity' => config_get_path('kea/loglevel', 'INFO')

in /etc/inc/services.inc.

EDaleH

@Gertjan

@Gertjan said in Feature #15321 shows how to use Option 114 in Kea:

And it works

Hopefully the Jan release of Plus will permit the data to be entered in the GUI but as long as the #15321 patch works with 24.11 Stable Release, which it does for us, we are good to go, I have had a loaded setup under test on the lab bench (60 users for the test) ever since the #1531 patch became available. It is running perfectly without issues. Our risk is that 25.01 is released and does not support the #15321 patch or GUI data entry. That would force us to continue using 24.11 or have the #15321 patch updated.

I would also like to point out that when changing from ISC to Kea, you should clear all DHCP leases. When you do this, your Captive Portal will have users approved that now get different IPs. That is a mess because if a new user gets the old authenticated IP, Captive Portal will think they are authenticated and not pop up the login screen (thru RFC8910 "true") leaving them in limbo as they also will not get internet access. Meanwhile the legitimate system will now get a log in screen even if they are authenticated and worse yet, Captive Portal will show both systems as logged in with the same MAC address and you won't know which is the wrong IP without going to DHCP leases.

The bottom line is you should log out all Captive Portal clients on all Portals before you switch from ISC to Kea to avoid this confusion. I raised a Redmine to see if they can include a feature to avoid this situation in a future release. See https://redmine.pfsense.org/issues/14119 if you want to add any suggestions.

Gertjan

@EDaleH said in Feature #15321 shows how to use Option 114 in Kea:

Hopefully the Jan release of Plus .... continue using 24.11 or have the #15321 patch updated.

The patch is an easy one. An extra entry box is added to the GUI, and the info entered is stored (and retried from) in the main pfSEnse config.
The second part is where this info (JSON structure) it is inserted on the right spot when the kea config file is created. Also pretty straight forward.
If 25.0x is any different, then it will be easy to modified it somewhat.

@EDaleH said in Feature #15321 shows how to use Option 114 in Kea:

I would also like to point out .... you want to add any suggestions.

I didn't even considered this as an issue, as I had just a couple of users connected when I was switching.
Switching from ISC to KEA is something that, in theory, only should happen ones . A small reminder 'somewhere' that portal users should be disconnected will do just fine.
Maybe converting the existing leases from from ISC leases file to Kea leases file when switching ? ( Yep, I'm joking ).

Btw : I always thought that an authenticated portal users were 'recognized' by a matching IP + MAC pair. If one of these two changes changes, the device (user) is considered being another device (user) and login has to reoccur.
But nope. The rfc8910 file just checks the IP if it is listed as a authenticated user, and doesn't check the MAC.