Reply duplication (on passive node in HA)

[jiuka]

Describe the bug

We run dhcrelay on both OPNsense HA Cluster nodes. The dhcrelay on the inactive node duplicates the replies to the client. TCPDump on the client shows the following.

0    07:51:39.346602    0.0.0.0        255.255.255.255    DHCP    346    DHCP Discover - Transaction ID 0x4808457e
1    07:51:39.348191    192.168.2.2    192.168.2.130      DHCP    348    DHCP Offer    - Transaction ID 0x4808457e
2    07:51:39.348514    192.168.2.3    192.168.2.130      DHCP    348    DHCP Offer    - Transaction ID 0x4808457e
3    07:51:39.348514    192.168.2.3    192.168.2.130      DHCP    348    DHCP Offer    - Transaction ID 0x4808457e

Analysis

The passive node forwards the requests from 192.168.2.3 to the dhcp server in a different subnet. The reply from the dhcp server however is routed via the active node and then received von the interface belonging to 192.168.2.3 where the dhcrelay is listening for dhcp (broadcast) packages. If i set a route on the dhcp server to route 192.168.2.3 directly to passive node, instead of active node (holding the carp ip) the duplication is not happening.

My guess is once processed as a reply and once picked from the interface as it is a udp packet to port 67.

Expected behavior

Both dhcrelay only send one relpy

Software version used and hardware type if relevant, e.g.:

OPNsense 25.4.3-amd64 on Deciso DEC4280

[fichtner]

This has been submitted in core where it can be fixed, but it wasn't merged yet. opnsense/core#8714

[jiuka]

Hi Franco,

I think this may be the underlying issue, which lead to the "carp-aware" issue / pr. But it has nothing to do with carp per se. It is happening when the dhcrelay receives the answer over the same interface as he serving as relay. So relayd is only working correctly when it is running on the active router. It may is of no concern for OPNsense, but there is no technical reason why the relayd needs to run on the router. In the topic raising the not carp-aware issue there is even proposed as a workaround to run a relay on dedicated vm. Something which would not work with this dhcrelay as it would always receive answers over the same interface as he serving.

DHCP should be perfectly happy with more then one DHCPOFFER. From multiple servers or from multiple relays. I have myself in my setup not seen any problems with the duplicated offers and acks. But i can imagin that some clients may get confused over it. But i would rather not disable one of the dhcrelay as this would remove part of the redundancy.

• Marius

[fichtner]

Hi Marius,

I don't understand this bit:

So relayd is only working correctly when it is running on the active router. It may is of no concern for OPNsense, but there is no technical reason why the relayd needs to run on the router.

Are we talking about actual relayd or still dhcrelay? I'm also not sure why running something not on a router is a "but" in the scope of OPNsense, but I'm likely misunderstanding something here.

Cheers,
Franco

[jiuka]

Hi Franco,

I talk about the dhcrelay the software in this repo. Currently it misbehaves (duplicates the replies) if it is not run on the (active) router of the network. On the (active) router of the network the replies are not received on the interface the dhcrelay is serving, but on the interface the dhcp server is configured to.

The OFFER or ACK from the DHCP Server to the dhcrelay process using the GIADDR which is the passive nodes IP in the client subnet. As this is not in the Subnet of the DHCP server it sends the packet to his default gateway. Which then forwards the packet in to the passive node using the client subnet. So the passive node receives the answer on the interface it listens for requests.

This probably triggers not only the got_response register via add_protocol in

dhcrelay/usr.sbin/dhcrelay/dhcrelay.c

Line 275 in 7335e6f

add_protocol("server", sp->fd, got_response, sp);

but the got_one registerd via register_interface too.

dhcrelay/usr.sbin/dhcrelay/dhcrelay.c

Lines 219 to 221 in 7335e6f

	if (interfaces == NULL ||
	register_interface(interfaces->name, got_one, 0) == NULL)
	fatalx("no interface given");

this would explain why one package received from the DHCP Server result in two packages send to the client.

I hope its now a bit clearer what i mean.

Regards,

• Marius