4

I was able to find a solution to this problem after much experimentation, so figured I would post it back in case anyone else encounters the same thing.

It looks as though some devices (Android and iOS, perhaps others too) would not complete a DHCP lease acquisition with dnsmasq if the IP offered was subject to an iptables rule to use a different default route. I’m still not precisely sure why this is, but perhaps the device tests its default route with the offered IP, sees its going to be given a default route different than the one in the main routing table and rejects the DHCP lease.

Instead, if I write the iptables rule to apply to a specific interface (vlan2) rather a range of IPs being offered on that interface, all devices will accept the lease and complete the transaction with dnsmasq. Perhaps in these instances, the device looks for a rule based on the offered IP, doesn’t see it will be diverted from the default route in the main routing table, and accepts the lease. Once joined, it routes correctly through the alternate default gateway specified for vlan2.

So instead of

ip rule add from 10.1.1.128/25 table streamer
ip route add default via $WAN_GW table streamer

This seems to work with all devices (also specified priority ahead of main table rule)

ip rule add iif br-vlan2 lookup streamer priority 999
ip route add default via $WAN_GW table streamer