Ok, I researched some more. There is a confusing array of behavior for different protocols when lb-local is set to enable or disable, so I made a table of what I found. In the table, eth3 and eth4 are my WAN interfaces, and have equal weight in the routing tables. eth4 is the primary WAN interface, and eth3 the secondary, failover-only interface. Anything in red is, it seems to me, behaving in an unexpected way, whereas anything in black is behaving correctly, even if it may be for the wrong reason.
| Command/Protocol | interface/s used with lb-local enable | interface/s used with lb-local disable |
| /bin/ping [host] | eth3/eth4 randomly | eth3/eth4 randomly |
| /bin/ping -I eth3 [host] | eth3 | eth3 |
| /bin/ping -I eth4 [host] | eth4 | eth4 |
| DNS from forwarding service, /usr/sbin/dnsmasq (UDP 53) | eth3/eth4 randomly | eth3/eth4 randomly |
| NTP from /usr/sbin/ntpd (UDP 123) | eth4 | eth3/eth4 randomly |
| curl [url] | eth4 | eth3/eth4 randomly |
| curl --interface eth3 [url] OR curl --interface 10.131.253.2 [url] (*) | eth4 | eth3/eth4 randomly |
curl --interface eth4 [url] OR curl --interface 10.131.254.2 [url] (*) | eth4 (**) | eth3/eth4 randomly |
* IP used is IP of the corresponding interface
** curl --interface eth4 is probably behaving correctly for the wrong reason in this case. Even though eth4 is specified, the traffic is probably going out eth4 because lb-local is enabled, not because the interface was specified.
