KEA Control Agent issues

[patient0]

Hi,

I setup an OPNsense 24.1 HA cluster on GNS3 to play with, well it started as an 23.7 cluster last week and then 24.1 happend .

router1 LAN IP = 192.168.1.2/24
router2 LAN IP = 192.168.1.3/24
Floating LAN IP= 192.168.1.1/24

I came across an issues in KEA:

The Control Agent 'Bind address' is synced from the primary to the secondary.

Means after HA sync both 'Bind address' are set to the primary, in my case 192.1.2. But IMHO it should be either left alone or magically set to the IP of the secondary IP.
I did read up on it and in the 'Configuration Template' section of KEA they seem to agree with me on that.

Thanks for a great product!

Edit: I originally thought I had an HA issue too but turned out that the HA peers URL can't be HTTPS, switching to HTTP solved that.

/Thomas

[rodovar]

after a lot of test and guessing i think i got the right message:

HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the OPNAGO1 is in the HOT-STANDBY state

use localhost in control agent address

use same port with ip of the interface in HA

leave empty This server name in "high availability"

hope it helps

[newsense]

Edit: I originally thought I had an HA issue too but turned out that the HA peers URL can't be HTTPS, switching to HTTP solved that.

Probably can, as long as you can validate certificates. 

[patient0]

...
use localhost in control agent address

use same port with ip of the interface in HA

Thank you for putting time into this. Although I don't think it will work that way. The Config Template  from the KEA documentation show the below pictures (and it does make sense; binding the control agent to localhost host, the other node can't communicate with him/her/it).

Does it work for you?

```
 +-host-1-+       +-host-2-+
 |        |       |        |
 |   CA <===\   /===> CA   |    ===== - HTTP connection
 |   #    |  \ /  |   #    |
 |   #    |   X   |   #    |    ##### - UNIX socket
 |   #    |  / \      #    |
 | DHCPv4 ==/   \== DHCPv4 |
 |        |       |        |
 +--------+       +--------+
```

Edit: You are right, I read that the other node doesn't need the CA to communicate, it's only for the us humans. But assume I want to use the RESTapi to control the KEA node, I want to bind it to non-localhost. And in that case the issue becomes ... well, an issue

I was hoping someone would confirm this use case and in the next step I'd (or he/she/they) would open a bug report.

[patient0]

Probably can, as long as you can validate certificates. 

I'm sure one can but how would I reference this certificate? Right now there's no way using the GUI and the config file is of course overwritten.

I'm not complaining btw, I'm aware that it's the first step in a probably longer way to have full KEA support.

[rodovar]

hi

tbh i didn't read kea original documentation, i just tried to make it work.

imo hostname and control agent shouldn't sync

now i am back to isc older version after i found the leases page completely empty

I'll probably gonna give another try in the 24.7 or 25.1 version

...
use localhost in control agent address

use same port with ip of the interface in HA

Thank you for putting time into this. Although I don't think it will work that way. The Config Template  from the KEA documentation show the below pictures (and it does make sense; binding the control agent to localhost host, the other node can't communicate with him/her/it).

Does it work for you?

```
 +-host-1-+       +-host-2-+
 |        |       |        |
 |   CA <===\   /===> CA   |    ===== - HTTP connection
 |   #    |  \ /  |   #    |
 |   #    |   X   |   #    |    ##### - UNIX socket
 |   #    |  / \      #    |
 | DHCPv4 ==/   \== DHCPv4 |
 |        |       |        |
 +--------+       +--------+
```

Edit: You are right, I read that the other node doesn't need the CA to communicate, it's only for the us humans. But assume I want to use the RESTapi to control the KEA node, I want to bind it to non-localhost. And in that case the issue becomes ... well, an issue

I was hoping someone would confirm this use case and in the next step I'd (or he/she/they) would open a bug report.