UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.

tgl

@johnpoz said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

My controller and APs are all on the same vlan, and this vlan is untagged because there is little reason to tag it

To add to that: it seems to be received wisdom on the UI forums that UniFi devices prefer their management VLAN to be untagged VLAN 1. You can make other choices work, but it's reportedly less reliable and more headache-filled.

johnpoz

@tgl doesn't have to be vlan 1 ;) just an untagged vlan.. Vlan 1 is just the default native untagged network on any switch that supports vlans.

Mine is vlan 2 for example. Pfsense doesn't have a clue about this tag, nor does the unifi gear - its just an untagged network, the only thing that knows about vlan 2 is the switching infrastructure. This is untagged to the devices are on this vlan and pfsense interface, and tagged for uplinks between my switches.

I make it simple to keep track off 192.168.2.0/24 is vlan 2, 192.168.3.0/24 is take a guess, vlan 3 ;) and etc etc.. what do you think my 192.168.7.0/24 vlan ID is - heheh

I got creative with a vlan I run that is 10.1.1.0/24 - its vlan ID is 1011 ;)

And I agree with normally infrastructure devices should be static.. My AP are static - let them get a dhcp IP to get going and then change them to static. Since an AP is not really something you can console directly into and set the IP. At least not the unifi ones.

Ghost 0

@johnpoz

@johnpoz said in UniFi access points successfully adopt under ISC DHCP but won't adopt when Kea DHCP is enabled.:

That being said, I am curious to why your APs are on 3 different vlans? Why would you not just put all your APs on the same vlan as your controller so you can just use L2 adoption.. Unless the controller is offsite from where your APs not sure I follow the logic to complicate your setup. I have a bunch of different vlans - the APs management IPs should be on their own vlan with your controller - ie a management vlan. My controller and APs are all on the same vlan, and this vlan is untagged because there is little reason to tag it, and when I can created the vlan unifi didn't even support tagged vlans - so why complex up the network switching to tagged when there is no reason too, etc.

I think my original post may have unintentionally created some confusion, thus let me clarify. My network is made up of two LAN's (LAN1 and LAN2). The UniFi controller is on LAN1 (10.1.1.X) as one of several programs on a Raspberry Pi4, and the UniFi access points reside on LAN2 (10.2.2.X). Despite my network having multiple vlans, the UniFi access points are not on different vlans. They are simply on a different subnet. These UniFi access points are vlan aware and support up to four unique internal vlan networks.

I did a little research on KEA DHCP. And according to Google AI, this issue that I'm experiencing is not unique. Here is an excerpt:

DHCP and UniFi Adoption:
UniFi access points use DHCP to obtain an IP address and discover the UniFi controller. They rely on DHCP option 43 to point them to the controller's IP address for adoption.

ISC DHCP vs. KEA DHCP:
Both ISC DHCP and KEA DHCP are DHCP servers, but they handle option configurations differently. If KEA isn't configured to include the correct option 43, the APs won't know where to find the controller.

Adoption Loop:
If the APs can't find the controller, they might repeatedly try to adopt, leading to a frustrating loop.

Question now is... Where in pfSense do I enter the "option 43" as suggested by the Google AI?

tgl

@Ghost-0 I think Google AI is full of it. I don't know what this "option 43" is, but I'm quite certain my own DHCP server doesn't send it. And I've not had trouble with adopting UniFi APs. Admittedly, I'm not trying to adopt across L2 domains, which would surely be more complicated.

You aren't too clear about how your LAN1 and LAN2 are connected --- are they a single L2 broadcast domain? If not, the shortest route to a working system might be to plug each new AP into LAN1 until it's adopted and knows who its controller is. The AP should remember that across reboots.

Ghost 0

***** "@tgl I think Google AI is full of it. I don't know what this "option 43" is, but I'm quite certain my own DHCP server doesn't send it. And I've not had trouble with adopting UniFi APs. Admittedly, I'm not trying to adopt across L2 domains, which would surely be more complicated.

You aren't too clear about how your LAN1 and LAN2 are connected --- are they a single L2 broadcast domain? If not, the shortest route to a working system might be to plug each new AP into LAN1 until it's adopted and knows who its controller is. The AP should remember that across reboots."*****

This is issue is no big deal, really. My network is humming fine without implementing the latest version of DHCP. I was just curious why it, ISC DHCP, has been deprecated from pfSense. It could be considered a little pet project borne out of curiosity. By the way, I'm somewhat disagree with your characterization of Google AI because the description of my issue given by Google AI was on point, whereas others here made a few assumptions regarding my issue instead of asking further questions.

To answer your question... the two LAN's are connected to separate managed switches and connect to the pfSense server via an Intel 4-port NIC . Not sure what you mean by L2 domain since I'm relatively a networking newbie. However, I hope this answered your question, though.

tgl

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

I was just curious why it, ISC DHCP, has been deprecated from pfSense.

I do know the answer to that, anyway: upstream development of ISC DHCP has been ended by ISC. They're instead working on its replacement KEA. As you've found, KEA doesn't seem to be entirely ready for prime time, so it was probably a bit premature of pfSense to mark ISC DHCP as "deprecated". But that is undoubtedly where things are headed --- though I wouldn't care to speculate as to the timeline.

johnpoz

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

curious why it, ISC DHCP, has been deprecated from pfSense

Because it was deprecated by ISC

https://www.isc.org/blogs/isc-dhcp-eol/

Its been in pfsense release notes going back a few versions now. They even had a blog post about - couple I think.

Here is the first one.

https://www.netgate.com/blog/netgate-adds-kea-dhcp-to-pfsense-plus-software-version-23.09-1

Why the change is necessary

The Internet Systems Consortium (ISC) distributes two full-featured, open-source, standards-based DHCP servers: Kea DHCP and ISC DHCP. ISC announced the End of Life (EOL) of the ISC DHCP server, and ended maintenance on it at the end of 2022.

As to google AI - this is not complete info,

DHCP and UniFi Adoption:
UniFi access points use DHCP to obtain an IP address and discover the UniFi controller. They rely on DHCP option 43 to point them to the controller's IP address for adoption.

Yes it can use dhcp option - but only needs to do that for L3 adoption - not when they are on the same L2. The rely on dhcp option is a hallucination - it ONLY needs that if your device and controller on not on the same L2 network.

https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

ITSpec1

@Ghost-0

I am not fully sure about your version. It might not be implemented yet. There is a work around though. I have been testing it in the plus version and it seems to work. See the link below it explains what needs to change i.e. patch pfsense to get dhcp options available in kea. Once you figure this out then you can configure your option 43 accordingly just like isc version. Unifi devices should pick up.

https://forum.netgate.com/topic/195391/pfsense-24-11-and-kea-option-43

Gertjan

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

I have this issue.

It starts with :

UniFi access points successfully adopt under ISC DHCP ...

because you had, and forgot that you did so, created an DHCP Option for ISC.

This means you have to create one under KEA also.

Now you know enough to solve the issue

Let's say you have a cloudkey hardware/software running on a LAN network host, I have one on 192.168.1.9 (a LAN IP).
You have on or more Unifi AP (or other Unifi stuff) on another network, let name one : 192.168.2.3

The easy way out : go here : Services > DNS Resolver > General Settings and create a Host override.
The host name should be 'cloud' (IRC) - the domain name could be your pfSense domain, and the IPv4 should be 192.168.1.9.

Better :
Go to your DHCPv4 KEA LAN settings page (the page that handles 192.168.1.0/24 network) and add :

{
  "option-data":  [
    {
      "name": "vendor-encapsulated-options"
    },
    {
      "name": "unifi",
      "space": "vendor-encapsulated-options-space",
      "csv-format": false,
      "data": "C0A80109" 
    }
  ]
}

Take note : syntax errors are not allowed. Ever ({[; space etc is important here.

=> this is an extra DHCP Custom '43' option, like in the good old ISC days.
The IP is encoded , and mine is 192.168.1.9.

Add also this "JSON Configuration" on every LAN interface where you have Unifi equipment.

Done.

Test (!) :
Packet capture on a network where you have UNifi equipment.
Use "UDP" and ports "67 68".
Now start/boot/power on a Unifi device.
You'll see the DHCP lease request.
You'll see the DHCP lease reply from the pfSense DHCP server, with the option "43", so the Unifi device will now know where to find the controller.

Check your the interfaces : firewall rules : the Unifi device should be able to communicate with the controller : 192.168.1.9 in my case.

ITSpec1

@Ghost-0

Based on what @Gertjan just posted. It seems the json configuration is available in your instance of pfsense. If you need a backup version to implement this outside of possibly not having a resolver and strictly just want dhcp 43 option to work you can try the config below. This is closer to the option 43 version of ISC type implementations just in KEA.

{
  "option-def": [
    {
      "space": "dhcp4",
      "name": "custom-option-vendor",
      "code": 43,
      "type": "binary"
    }
  ],
  "option-data": {
    "opt7": [
      {
        "name": "custom-option-vendor",
        "data": "01 04 C0 A8 19 02"
      }
    ],
    "opt25": [
      {
        "name": "custom-option-vendor",
        "data": "01 04 C0 A8 19 02"
      }
    ]
  }
}

Two areas need to change to suit your configuration. What interface your trying to attach the 43 option to. You can find this by navigating Status -> Interfaces choose the (optxx) interface you want to attach it to usually the network the ap's live on. Then configure the data portion below each (opt) of that json configuration. Using the IP address of your controller with decimal to hex equivalent. Like the previous poster mentioned be very careful for syntax errors or spaces.

Ghost 0

@Gertjan
Thanks for the reply and the step-by-step instructions! I'm going implement it ASAP and hopefully, it will work. I just noticed another issue when KEA DHCP is enabled... I'm unable to access resources on LAN1 (10.1.1.x) from LAN 2 (10.2.2.x). This stuff is so complicated for a newbie but glad this forum exists for users like me This is so weird. Deactivated KEA and using ISC DHCP for now until this KEA thing is resolved. Again, thanks for the info!

johnpoz

@Ghost-0 what dhcp server you use has zero to do with accessing another vlan.. Unless the devices are not getting the gateway, then no they wouldn't be able to get to another vlan or the internet. Not going to get to another network if you have no gateway.

Ghost 0

@ITSpec1

Much obliged for taking the time for researching this for me and thanks for the link! I will read and try it if it's not too complicated to implement for a newbie.

Gertjan

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

I will read and try it

I've edited my post above.
A second, JSON text structure is also needed. It has to be 'defined' first :

{
  "option-def": [
    {
      "name": "unifi",
      "code": 1,
      "space": "vendor-encapsulated-options-space",
      "type": "string"
    }
  ]
}

on the main

page.

Then, as said earlier, on every interface where you need the DHCP option 43, you have to put :

{
  "option-data":  [
    {
      "name": "vendor-encapsulated-options"
    },
    {
      "name": "unifi",
      "space": "vendor-encapsulated-options-space",
      "csv-format": false,
      "data": "C0A80109" 
    }
  ]
}

where "C0A80109" is hex for 192 168 1 9 => 192.168.1.9 if your controller uses 192.168.1.9 (an IP on my LAN network).
So you probably have to adapt that hex string.
The rest can be copied and places as-is.
That's in newbie range ^^