HA configuration is corrupted when the VRRP interface is not named `lan`

[cotosso]

Description

When creating an HA cluster using a dedicated VRRP interface with a logical name different from lan, such as trunk_ha, the Keepalived configuration is initially created using lan_* identifiers.

The initial configuration for trunk_ha is created with sections and names such as lan_ha, lan_track and lan_delays. When a real interface named lan is later added to the HA monitored interfaces, its HA configuration is corrupted when the VRRP interface is not named lanconfiguration reuses the same identifiers and overwrites the tracking and delay configuration previously associated with the VRRP interface.

This corrupts the HA configuration because the VRRP interface tracking can be replaced by the lan interface tracking, potentially breaking failover behavior.

Steps to reproduce

1. Create an interface to be used for VRRP with a name different from lan, for example trunk_ha.
2. Initialize the HA cluster using trunk_ha as the VRRP interface.
3. Create another interface named lan.
4. Add the lan interface to the HA monitored interfaces.
5. Check /etc/config/keepalived.

Actual behavior

The initial HA configuration for trunk_ha uses lan_* identifiers, for example:

config track_interface 'lan_track'
	option name 'lan_ha'
	option value 'eth0'
	option ns_link 'network/trunk_ha'

config interface_up_down_delays 'lan_delays'
	option device 'eth0'

After adding the real lan interface to HA, the same sections are reused and overwritten:

config track_interface 'lan_track'
	option name 'lan_ha'
	option value 'eth3'
	option ns_link 'network/lan'

config interface_up_down_delays 'lan_delays'
	option device 'eth3'

As a result, the tracking and delay configuration for the original VRRP interface is lost or changed to point to the lan interface.

Expected behavior

The HA initialization should not hardcode lan_* identifiers when the VRRP interface is not named lan.

If the VRRP interface is named trunk_ha, Keepalived sections should use identifiers derived from that interface name, for example:

config track_interface 'trunk_ha_track'
	option name 'trunk_ha_ha'
	option value 'eth0'
	option ns_link 'network/trunk_ha'

config interface_up_down_delays 'trunk_ha_delays'
	option device 'eth0'

When a real lan interface is later added to HA, it should create independent lan_* sections without overwriting the VRRP interface configuration.

Components

NethSecurity 8.7.2.

[cotosso]

We evaluated a possible fix for this issue.

The current implementation uses lan_* identifiers during the initial HA configuration.
This does not cause problems as long as there is no additional HA interface named lan.

Changing the initial HA configuration to generate identifiers based on the actual VRRP interface name could introduce regressions on existing installations that are currently working with the current naming scheme.

For this reason, we propose a safer approach:

• add a validation check during HA interface configuration to prevent adding an additional HA interface named lan when the main VRRP interface is not named lan

• document as a best practice that the interface used for VRRP should be named lan.

This prevents the known configuration collision while minimizing the risk of regressions on existing deployments.

[cotosso]

docs:
NethServer/nethsecurity-docs#261

[github-actions]

Testing image version: 8.7.2-dev+73f1c8cf8.20260514120334

Test case

• Try to reproduce the issue
• When adding an interfaced named lan as a second interface, the command should fail with a validation error