Cascaded Router Admin Panel/Access Issue

Hello,
I have a two router setup that is shown in diagram below.

The Brume3 (MT3000) 192.168.8.1 acts as Primary Gateway, connects to Fiber Modem (192.168.1.1) via WAN1; LAN1 is converted to WAN2, this connects to Brume 2(MT2500) 192.168.7.1.
WAN1 and WAN2 are in failover model (WAN1 Fiber goes down → Use WAN2 which is Brume 2).
An Eero WiFi router connects to LAN of Brume 3 (MT3000) and provides WiFi access to clients.

The Brume2 has USB 5G/4G modem acting as WAN (USB modem is RNDIS type, 192.168.6.1).
Brume2’s WAN port is converted to LAN, and this connects to Brume3 (MT3000) and assigns IP 192.168.7.2. Additionally a Raspberry Pi is connected via LAN port with 192.168.7.3.

Now, when Fiber goes down, the failover works just fine. Internet is working from clients (Client → Eero → Brume3 → Brume 2 → USB 4G/5G Modem).

From Client I can access Admin Panel of Brume 3 at 192.168.8.1. I can also access Admin Panel of Fiber Modem at 192.168.1.1. However I cannot access Brume 3 Admin Panel at 192.168.7.1 or the Raspberry Pi at 192.168.7.3 or the Admin Panel of 4G/5G modem at 192.168.6.1.

Please provide help on how to resolve this issue!

Hi,

That’s a bit unusual, as you should theoretically be able to access 192.168.7.0/24 without any issues.
You might want to trace the route on your PC:

# Windows (Command Prompt)
tracert 192.168.7.1

# macOS / Linux
traceroute 192.168.7.1

As for accessing 192.168.6.1, you’ll need to configure a static route on the Brume 3 (MT5000) so that the relevant traffic is forwarded to the Brume 2 (MT2500) for handling.
Go to LuCI → Network → Static Routes and add the following:

Please note that if the WAN2 interface is detected by Multi-WAN as having no internet connectivity, this static route may become invalid. In that case, go to Admin Panel → Network → Multi-WAN and disable “Enable Interface Status Track” for WAN 2 so it won’t be marked as dead route.

Thank you for the inputs.
Weirdly next day the issue was self-resolved. Perhaps there was some weird caching in the primary gateway?

1 Like

Thank you for the update—we’re glad to hear the issue has been resolved.