I get this message. Not sure what is going on.
Status looks ok.
master settings
backup settings
What about the web server settings? Looks like you are accessing the gateway on a different IP than the configured bind address.
Both servers are running dual NICs. Redundancy is setup between 10.9.254.5 and 6.
Gateways are 10.9.150.5 and 6
While highly desirable for many applications, this plays havoc with redundancy if Ignition clients can connect through either network.
The only good solution I'm aware of is to have DNS on all networks resolve names for these gateways, in such a way that the IP returned for your gateway to a client is the correct address for that client's network.
Then the Public HTTP Address setting that Kevin points out can be set to the domain name and all of your clients will "just work" using that name.
{FWIW, the setting in dnsmasq for the desired response behavior is called "localize queries".}
Ignition clients can only connect on the one network.
The other NICs (reduncany channel) are wired right to each other.
The servers are on DNS
Connect by name, then. Put the server names in the Public HTTP Address setting.
Also, your original graphic suggests that your network for clients to connect to the backup server died while the network between your gateways was still running. This is a pathological condition that Ignition redundancy cannot handle. It suggests that you have configured redundancy between servers that don't expose the same subnet on the client side, perhaps because you are trying to make the backup server remote. (Not supportable, partly due to this phenomenon.)
If the servers are not remote from each other, just get rid of the separate network for redundancy. You want your server-to-server connection to die at the same time as the client-to-active-server connections.
Did this change w/ V8?
This setup worked w/ V7.9
You may think it worked in v7.9, but I do not see how it possibly could have. For the specific case of a client losing its connection to an active server while the active server was still happily synced to its peer. The server-to-server connection has to break to cause a failover.
I'll try your suggestions when their VPN is back up. 
Thanks.