VRRP unexpected ARP results

We are in the middle of our first VRRP deployment (which happens to be for our biggest client). We have been having a lot of difficulty (which in turn has also caused our client some major pains).

Basically we are seeing intermittent ARP replies coming from the NG that has the lower VRRP priority, and therefore should NOT be replying to ARP requests for the VRRP alias addresses.

Initially we though this was only happening for a 2nd VRRP alias address that was configured on 1 physical interface between both NGs. So as a temporary troubleshooting measure, we took the 2nd VRRP alias address off of one of the NGs, and this seemed to resolve the issue for that affected IP address. Or so we thought. However, today we are seeing more signs that the NG with the lower VRRP priority is in fact still responding to ARP requests for this VRRP alias address that isn't even configured on the NG's physical interface (but which is configured on the physical interface of the NG that is its VRRP peer).


Peculiarities that might be unique to our scenario of VRRP usage:

1. Some of the interfaces are tagged VLAN interfaces, rather than dedicated physical interfaces.
2. We have 4 interfaces that we're currently trying to run VRRP with (2 internal data VLANs, 2 different external WANs).
3. We have 2 VRRP Alias addresses on one of our interfaces (initially we had this address configured on both NGs, but after having erratic inexplicable ARP replies coming out of the NG with the lower VRRP priority on that interface, we chose to remove the 2nd VRRP Alias address from the backup NG).
4. We have a higher VRRP priority on one NG for all interfaces, except for 1 interface. That particular interface is the backup WAN internet connection. It has a higher VRRP priority on the other

At this point, the questions we are asking are:

1. What is the correlation between VRRP and the strange RFC ARP reply issue discussed here: http://forums.untangle.com/networkin...wan-isps.html (I am asking this particularly in regards to the fact that at the time of that thread, Untangle NG's behavior was to respond to ARP request on any interface where an ARP request is seen, regardless of whether that particular NG IPv4 address is actually assigned and reachable on that particular NG interface.)
2. What will Untangle NG do when it receives a packet destined to one of its VRRP Alias Addresses during a time that it is not the higher VRRP priority? Will it discard the packet, or process it?
3. What is the behavior we should expect when mixing higher VRRP priorities on *different* interfaces/instances across 2 Untangle NGs? Although we have since decided that in our case this would break NAT and over-complicate the design, we still don't think that the higher VRRP priority on the outside interfaces, should have caused the backup UTM to reply to ARP requests on the internal interfaces where it actually had a lower VRRP priority.
4. Does VRRP actually have any more functionality on the behavior of Untangle NG, than simply affecting NG's ARP replies? Or does VRRP actually go deeper into the NG's logic/processing behavior? Such as, would VRRP affect not only the packets ingressing NG, but also determining the external NAT source address to use with the packets egressing NG (assuming VRRP is configured on both the internal and external/WAN interfaces)?
5. Is there any type of logging/status available that we can look at when attempting to troubleshoot VRRP behavior? It would be extremely helpful if we could see each NG giving its own indication of whether it thinks it is the active VRRP peer, as well as logging the results of each VRRP heartbeat.