VIPs service binding behavior and UI is inconsistent

[opn_nwo]

Here is what I notice about the new service binding feature for VIPs:

-

• NTPd is still binding to VIPs even if the new "allow service binding" is unchecked and the VIP is not selected in the interface list
• In Unbound the VIPs are not listed in the interfaces dropdown (they are for NTP) and it will not bind to them if "allow service binding" is disabled

The two behaviors are inconsistent in the UI. Either have all services abide by the "allow service binding" or (better) make the "no binding" the default behavior and allow the selection of VIPs in interfaces dropdowns across the UI.

[tiermutter]

NTPd is still binding to VIPs even if the new "allow service binding" is unchecked and the VIP is not selected in the interface list

I observed the same, mentioned in German forum (https://forum.opnsense.org/index.php?topic=26562.msg128334#msg128334). DNS (AdGuard) listens to that interface even if the option is unchecked. Thats why I was a bit confused about the behaviour of this option.

[franco]

Different subsystem use different approaches for historic reasons. Our settled approach is to not be able to select interfaces/aliases/carp and bind to all automatically through interfaces_addresses() which also supports "nobind". I did a number of those conversions, i.e.:

Code: [Select]

% git grep interfaces_addresses\(
src/etc/inc/filter.lib.inc:                foreach (array_keys(interfaces_addresses($ifcfg['if'], true, $fw->getIfconfigDetails())) as $addr) {
src/etc/inc/interfaces.inc:    foreach (array_keys(interfaces_addresses($realif, true, $ifconfig_details)) as $tmpiface) {
src/etc/inc/interfaces.inc:function interfaces_addresses($interfaces, $as_subnet = false, $ifconfig_details = null)
src/etc/inc/interfaces.inc:    foreach (interfaces_addresses($realif, true, $ifconfig_details) as $tmpaddr => $info) {
src/etc/inc/interfaces.inc:    foreach (interfaces_addresses($realif, true, $ifconfig_details) as $tmpaddr => $info) {
src/etc/inc/plugins.inc.d/dnsmasq.inc:        foreach (interfaces_addresses($interfaces) as $tmpaddr => $info) {
src/etc/inc/plugins.inc.d/openssh.inc:    foreach (interfaces_addresses($interfaces) as $tmpaddr => $info) {
src/etc/inc/plugins.inc.d/unbound.inc:        foreach (interfaces_addresses($active_interfaces) as $tmpaddr => $info) {
src/etc/inc/plugins.inc.d/unbound.inc:    foreach (interfaces_addresses(array_keys($active_interfaces), true) as $subnet => $info) {
src/etc/inc/plugins.inc.d/webgui.inc:    foreach (interfaces_addresses($interfaces) as $tmpaddr => $info) {
src/etc/inc/xmlrpc/legacy.inc:    foreach (array_keys(interfaces_addresses($realif, true)) as $vipips) {
If you want to take a stab at other subsystems like NTP and try to migrate that away from the previous approach without breaking setups be my guest. PRs welcome.


Cheers,
Franco

[opn_nwo]

I understand and I like the new approach. But for NTP the implementation is currently broken. NTP will bind to all VIPs regardless of the "allow service binding" or whether the VIP is unselected in the UI dropdown.

[franco]

Let's not discuss the meaning of "broken". NTPD gets the interface name on the system and binds to it. That is how NTPD works and always has, e.g.:

interface listen em0

We have no business deciding fron that point on.


Cheers,
Franco

[opn_nwo]

Sure, if NTP does not support VIPs, that's fine, but then why show the VIPs in the interface dropdown in the NTP UI? That's what I meant by "broken". The UI is providing an option that does nothing whether is selected or not.

[franco]

> but then why show the VIPs in the interface dropdown in the NTP UI

Because you can bind to the VIP only as IP address... It's been this way for over a decade.

As I said PRs welcome. As for seamless migration it's likely impossible and I'm not sure this is worth a breaking change.


Cheers,
Franco

[lilsense]

why not just use Chronyd. which solves the problem; include only the subnets to listen and respond.

[opn_nwo]

> but then why show the VIPs in the interface dropdown in the NTP UI

Because you can bind to the VIP only as IP address... It's been this way for over a decade.

As I said PRs welcome. As for seamless migration it's likely impossible and I'm not sure this is worth a breaking change.


Cheers,
Franco

Just last clarification because I'm probably not explaining myself. Is it the expected behavior for NTP to bind to a VIP (unselected in the dropdown) if the parent interface is selected and the "allow service binding" in the VIP settings is disabled?

In the attached screenshots LAN (10.1.60.1) is the parent interface of the Test VIP (10.1.60.7). NTP is binding to .7 even if it is not selected. Is that the correct behavior?

[franco]

I did explain it. When you select an interface it is added to ntpd.conf as such:

interface listen em0

The decision to bind to all addresses on em0 is done by NTPD as it doesn't know anything about VIPs and such.

What we've done to straighten out VIP support and the eventual no-bind feature (it's still new since 22.1) pertains to the ability to filter addresses on an interface (e.g. em0) according to their properties/origin. Potentially we can only clean this up by stopping to emit "em0" to ntpd.conf in some sort.


Cheers,
Franco