Tailscale connection fails after MultiWAN failover from Starlink to mobile SIM on RUTX50

Networking Solutions Issue
1

Dear Teltonika Support Team,

I am using a Teltonika RUTX50 with Starlink Mini connected to the WAN port and a Telekom SIM card as mobile failover. Starlink is running in bypass mode. Tailscale is installed directly on the RUTX50 and is used for remote access and data routing.

The intended setup is that Starlink is the primary connection and the Telekom SIM is used as fallback. In normal operation, when Starlink is available, Tailscale works correctly. When I cover the Starlink antenna and the router switches to the Telekom SIM, normal internet failover appears to work correctly, but the Tailscale connection on the router goes offline and does not recover automatically.

When Starlink is covered, mwan3 status shows that wan1 is offline and mob1s1a1 is online and used as 100% of the active IPv4 policy. However, Tailscale still cannot connect. tailscale netcheck reports UDP: false, IPv4: (no addr found) and Nearest DERP: unknown.

I investigated the routing and found that Tailscale-marked traffic still seems to be routed via the Starlink WAN interface, even though Starlink is unavailable. The command

ip route get 8.8.8.8 mark 0x80000

returns:

8.8.8.8 via 100.64.0.1 dev eth1 src 100.65.225.216 mark 0x8000

So traffic with Tailscale’s fwmark 0x80000 is still routed through eth1, which is the Starlink interface. At the same time, the active failover interface should be mob1s1a1 / qmimux0.

I also noticed the following rule in ip rule show:

1310: from all fwmark 0x80000

The main routing table still contains the Starlink default route with a better metric than the mobile route:

default via 100.64.0.1 dev eth1 … metric 1

default dev qmimux0 … metric 3

This seems to cause Tailscale control/DERP/STUN traffic to remain on the unavailable Starlink route instead of following the active MultiWAN failover policy.

As a test, I manually added the following rule:

ip rule add pref 1200 fwmark 0x80000/0xff0000 lookup 1

Could you please advise how Tailscale should be configured on a RUTX50 with MultiWAN failover so that Tailscale-marked traffic follows the currently active failover interface?

Also, is this behavior known in firmware RUTX_R_00.07.22, and would updating to a newer firmware version potentially resolve this MultiWAN/Tailscale routing issue?

Thanks in advance and kind regards

Thomas Mommsen

2

This is what Claude tells me:

Claude responded: Yes, you can solve this with a custom script!

Yes, you can solve this with a custom script! Your diagnosis is spot-on — the issue is that Tailscale’s fwmark (0x80000) hits rule 1310 which bypasses the MultiWAN policy and falls through to the main routing table, where Starlink’s metric-1 default route wins even when the interface is down.

Here’s a robust script approach:

The Core Problem

Tailscale packet → fwmark 0x80000 → rule 1310 → main table → metric 1 (Starlink, dead) ✗
                                                             ↗
Should go → MultiWAN policy table (active interface) ✓

Solution: Custom Hotplug + Init Script

1. Create the routing fix script

bash

cat > /etc/tailscale-mwan-fix.sh << 'EOF'
#!/bin/sh
# Fix Tailscale fwmark routing to follow MultiWAN failover
# Tailscale uses fwmark 0x80000 (mask 0xff0000)

TAILSCALE_MARK="0x80000"
TAILSCALE_MASK="0xff0000"
RULE_PREF=1200
MWAN_TABLE=1          # mwan3 typically uses table 1 (verify with: ip rule show)

add_tailscale_rule() {
    # Check if rule already exists
    if ! ip rule show | grep -q "pref ${RULE_PREF}.*fwmark ${TAILSCALE_MARK}/${TAILSCALE_MASK}"; then
        ip rule add pref ${RULE_PREF} fwmark ${TAILSCALE_MARK}/${TAILSCALE_MASK} lookup ${MWAN_TABLE}
        logger -t tailscale-mwan "Added fwmark routing rule (pref ${RULE_PREF})"
    else
        logger -t tailscale-mwan "Rule already present, skipping"
    fi
}

remove_tailscale_rule() {
    ip rule del pref ${RULE_PREF} fwmark ${TAILSCALE_MARK}/${TAILSCALE_MASK} lookup ${MWAN_TABLE} 2>/dev/null
    logger -t tailscale-mwan "Removed fwmark routing rule"
}

case "$1" in
    start|add)   add_tailscale_rule ;;
    stop|remove) remove_tailscale_rule ;;
    restart)     remove_tailscale_rule; add_tailscale_rule ;;
    *)           add_tailscale_rule ;;  # default: add
esac
EOF

chmod +x /etc/tailscale-mwan-fix.sh

Verify your mwan3 table number first:

bash

ip rule show | grep mwan
# Look for lines like: 1000: from all lookup 1  ← this "1" is MWAN_TABLE

2. Hotplug script — re-applies rule on interface changes

bash

cat > /etc/hotplug.d/iface/99-tailscale-mwan << 'EOF'
#!/bin/sh
# Re-apply Tailscale routing fix whenever an interface comes up or failover occurs

case "$ACTION" in
    ifup|ifupdate)
        logger -t tailscale-mwan "Interface $INTERFACE came up — refreshing Tailscale rule"
        /etc/tailscale-mwan-fix.sh restart
        # Give mwan3 a moment to update its tables first
        sleep 2
        /etc/tailscale-mwan-fix.sh restart
        ;;
esac
EOF

chmod +x /etc/hotplug.d/iface/99-tailscale-mwan

3. Init script — survives reboots

bash

cat > /etc/init.d/tailscale-mwan-fix << 'EOF'
#!/bin/sh /etc/rc.common

START=99
STOP=10
USE_PROCD=1

start_service() {
    /etc/tailscale-mwan-fix.sh start
}

stop_service() {
    /etc/tailscale-mwan-fix.sh stop
}

restart() {
    /etc/tailscale-mwan-fix.sh restart
}
EOF

chmod +x /etc/init.d/tailscale-mwan-fix
/etc/init.d/tailscale-mwan-fix enable
/etc/init.d/tailscale-mwan-fix start

4. Verify it’s working

bash

# Check the rule is in place at pref 1200 (before rule 1310)
ip rule show | grep -E "1200|1310|80000"

# Should now resolve via mob1s1a1 / qmimux0, not eth1
ip route get 8.8.8.8 mark 0x80000

# Watch logs during a failover event
logread -f | grep tailscale-mwan

Regarding Firmware RUTX_R_00.07.22

This is a known interaction issue rather than a strict firmware bug — Tailscale’s fwmark intentionally bypasses policy routing (by design, to avoid loops), which conflicts with how mwan3 implements failover. That said:

Firmware track Notes
00.07.22 (your version) Known to have mwan3/Tailscale fwmark conflicts
00.07.8+ / 00.07.9+ Some mwan3 table handling improvements
Latest stable Worth checking Teltonika’s changelog for explicit mwan3 fixes

Check for updates at: System → Firmware → Check for updates in the WebUI, or visit wiki.teltonika-networks.com.

A firmware update may help, but since this is fundamentally an fwmark priority conflict, the script above will likely be needed regardless of firmware version — newer firmware won’t change the fact that rule 1310 (pref < mwan3 policy) intercepts Tailscale traffic first.

6

Hello @pwhooftman,

thanks a lot for taking the time to respond to my issue.

I have installed the Teltonika router on an unmanned survey vessel. Therefore, I need to be absolutely certain that the failover is triggered correctly and that I still have access via Tailscale afterwards.

I would therefore appreciate it if @Teltonika could briefly comment on this issue — specifically whether an adjustment is planned or whether there is a known software-side workaround.

If necessary, I could also use an AI-generated script, but I would always prefer an official Teltonika solution first, as I cannot be sure whether my scripted modification might affect other Teltonika software parameters and potentially cause bugs.

Best regards

7

Hey Teltonika Team,

is there already an idea of how to solve my problem?

Thanks in advance and kind regards

Thomas