Incorrect ARP entry for directly-connected VRRP BACKUPs' non-VIPs - why?

[wedwards]

Disclaimer: this may actually be a BSD networking question, but posting here as I'm not sure yet.

Situation

• pfSense has IP 185.233.175.160
• lb1-1.ha.cyberfusion.cloud has IP 185.233.175.139
• lb1-0.ha.cyberfusion.cloud has IP 185.233.175.175
• lb1-{0,1}.ha.cyberfusion.cloud share the VIP 185.233.175.190 (VRRP)
• lb1-1.ha.cyberfusion.cloud is VRRP BACKUP

Problem

• lb1-1.ha.cyberfusion.cloud has IP 185.233.175.139 (not the VIP!)
• lb1-1.ha.cyberfusion.cloud is VRRP BACKUP
• IP 185.233.175.139 is on ens18
• ens18 has MAC address ea:c3:bc:0c:e4:09
• pfSense's ARP table contains MAC address 00:00:5e:00:02:80, which is the VRRP interface's MAC address (vrrp6.119@ens18)

Question: why is 185.233.175.139's ARP entry 00:00:5e:00:02:80 (interface vrrp6.119@ens18, which does not have the IP address!), rather than ea:c3:bc:0c:e4:09 (interface ens18, the interface that the IP address is actually on)?

Other directly-connected machines do have a correct ARP entry:

root@lb1-0:~# ip -4 neig list | grep 185.233.175.139
185.233.175.139 dev ens18 lladdr ea:c3:bc:0c:e4:09 REACHABLE

... while pfSense's ARP entry looks like this:

185.233.175.139   00:00:5e:00:02:80    lb1-1.ha.cyberfusion.cloud

Interface configuration on lb1-1.ha.cyberfusion.cloud

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether ea:c3:bc:0c:e4:09 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 185.233.175.139/25 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 2a0c:eb00:0:f7:185:233:175:139/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::e8c3:bcff:fe0c:e409/64 scope link
       valid_lft forever preferred_lft forever

24: vrrp6.128@ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:5e:00:02:80 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::e8c3:bcff:fe0c:e409/64 scope link nodad deprecated
       valid_lft forever preferred_lft 0sec

Good to know

• This is NOT about VRRP on pfSense itself!
• This may actually be a BSD networking question.
• The incorrect ARP entry is NOT for the VIP, but for an IP address on ens18 (the VRRP interface's parent interface).
• NDP entries are correct, i.e. this problem does not exist for IPv6
• This happens for all directly-connected VIP addresses. lb1-{0,1}.ha.cyberfusion.cloud is just one of those cases.