Device: RUTX50
Firmware: RutOS (current stable)
Feature: Mobile passthrough mode with MAC-based client assignment
Description
We have been setting up a RUTX50 as a 5G failover uplink for an office network. The passthrough feature works correctly in a simple topology (downstream device connected directly to a standard LAN port), but fails silently when the passthrough port is isolated into its own VLAN — a configuration needed to prevent DHCP conflicts with the existing office LAN.
In this scenario, the downstream device (a UniFi UDM-Pro configured as WAN2) correctly receives the carrier IP address via DHCP, but never receives the default gateway. As a result it has no internet access despite the DHCP lease appearing valid.
What we found
After some digging, we were able to restore connectivity by manually correcting the routing table entries and adding a hotplug script to reapply them on mobile interface reconnects. The routing rules that get set up automatically during passthrough initialization were pointing to the main LAN bridge (br-lan) rather than the VLAN-isolated bridge (br-lan1) where the downstream device actually resides.
While investigating, we also inspected /tmp/dnsmasq.d/bridge — we did not modify it, as it is clearly a generated file — but its contents confirmed the pattern: all interface references in that file point to br-lan regardless of the actual bridge topology.
Our hypothesis
Since /tmp/dnsmasq.d/bridge is regenerated automatically on each reconnect, and its contents reflect the same incorrect bridge assumption we found in the routing tables, we believe the root cause is in /lib/functions/mobile.sh, which appears to be the component responsible for generating both that file and the routing rules. If that function has the bridge interface name hardcoded, it would explain the consistent behavior across all affected configurations.
We have not modified mobile.sh itself — we preferred to work around the issue at the routing level rather than risk destabilizing the system.
Request
Could you confirm whether this is a known limitation, and whether there is a supported way to configure passthrough when the target port is on a VLAN-isolated bridge? If this is indeed a bug, we’d be happy to provide further diagnostic output (routing tables, dnsmasq config, interface status) to help reproduce it.
Thank you for the great product — aside from this issue, the RUTX50 has been working very well.
Kind regards,
Miguel Erill.