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

[DeepBlueSurvey]

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

[pwhooftman]

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.

[DeepBlueSurvey]

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

[DeepBlueSurvey]

Hey Teltonika Team,

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

Thanks in advance and kind regards

Thomas

[DeepBlueSurvey]

Good morning Teltonika,

are there any news on my topic? Unfortunately, the problem resists and I need to find a solution to use my router on my boat properly.

Thanks in advance and kind regards

[Vilius]

Greetings, @DeepBlueSurvey ,

I hope you’re doing well,

Sincerest apologies for a late response. To isolate the issue with Tailscale disconnecting after failover (Starlink → mobile SIM), please perform the checks below and provide the results.

Troubleshooting steps

1. After failover occurs, verify routing state:

ip rule showip route show table mainip route get 8.8.8.8

2. Restart Tailscale after failover and confirm if connectivity restores:

/etc/init.d/tailscale restart

3. Check MultiWAN configuration:

• Is “Flush connections on failover” enabled?
• Are both WAN interfaces assigned to correct firewall zones?

4. Collect Tailscale diagnostics after failover:

tailscale statustailscale netcheck

Additionally, could you please clarify the following:

• Does restarting Tailscale always restore connectivity after failover?
• Which firmware version is currently used on the RUTX50?
• Does the issue happen on every failover or intermittently?

Kind regards,
V.

[DeepBlueSurvey]

Hello Vilius,

thank you for your response. To trigger the failover from WAN (Starlink Mini in bypass mode) to Mobile SIM (Telekom), I covered the Starlink antenna. Afterwards, I ran the test and received the following result:

"root@RUTX50:~# ip rule show

0: from all lookup local

1001: from all iif qmimux0 lookup 1

1003: from all iif eth1 lookup 3

1310: from all fwmark 0x80000/0xff0000 lookup m ain

1330: from all fwmark 0x80000/0xff0000 lookup def ault

1350: from all fwmark 0x80000/0xff0000 unreac hable

1370: from all loo kup 52

2001: from all fwmark 0x100/0x3f00 l ookup 1

2003: from all fwmark 0x300/0x3f00 lookup 3

2061: from all fwmark 0x3d00/0x3f00 blackhole

2062: from all fwmark 0x3e00/0x3f00 u nreachable

3001: from all fwmark 0x100/0x3f00 unreachable

3003: from all fwmark 0x300/0x3f00 unreachable

32766: from al l lookup main

32767: from all lookup default

root@RUTX50:~# ip route show table main

default via 100.64.0.1 dev eth1 proto static src 100.65.22 5.216 metric 1

default dev qmimux0 proto static scope link src 10.15 5.0.125 metric 2

10.155.0.125 dev qmimux0 proto static scope link src 10. 155.0.125 metric 2

100.64.0.0/10 dev eth1 proto static scope link src 100. 65.225.216 metric 1

192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.5

root@RUTX50:~# ip route get 8.8.8.8

8.8.8.8 via 100.64.0.1 dev eth1 sr c 1 0 0 . 65. 225.216 uid 0

cache"

Afterwards, I restarted Tailscale on both my Windows laptop and on the Teltonika* according to your instructions. Unfortunately, the restart didn’t change anything. Tailscale remains offline on the Teltonika. The laptop was reconnected.

"root@RU T X 5 0 : ~# tailscale status

# Health check:

# - You are logged out. The last login error was: fetch control key: Get "https://controlplane.tailscale.com/key?v=131": context canceled

unexpected state: NoState

root@R UTX50:~# tailscale netcheck

2026/07/04 13:49:41 No DERP map from tailscaled; using default.

2026/07/04 13:49:41 attempting to fetch a DERPMap from https://control p l a n e .tailsca le.com

Report:

* Time: 2 0 2 6 -07-04T13:49:47.62864 3242Z

* IPv4: (no addr found)

* IPv6: no, but OS has support

* M a p p i n gVariesByDestIP:

* PortMapping:

* CaptivePortal: false

* Nearest DERP: unk nown (no response to latency probes)

“Flush connections on failover” is active for WANIPv4.

Firewall settings are as follows:

Tailscale always reconnects automatically after reconnecting to WAN (Starlink).

I am using the latest firmware version (please see screenshot attached).

Yes, Tailscale goes always offline after a failover from WAN to mobile and comes back after switching back from mobile data to WAN.

If it helps, you are welcome to connect to my computer via TeamViewer or similar software to gather more information for troubleshooting.

Best regards

Thomas

[pwhooftman]

If the Starlink Mini has a static ip address at the WAN port, this seems the cause:

Tailscale client fails to connect when using mwan3 with static IP on primary WAN interface

If you are able to assign a dynamic ip address to the Starlink Mini on the WAN port the problem may be resolved. Or set up a script like in the github post.
I

[Justinas]

Greetings,

For troubleshooting purposes, we will require more sensitive information from your end, such as the troubleshooting file, which may contain passwords, public IP addresses, serial numbers, and such. To avoid leaking this information, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 19759.

Best Regards,
Justinas

[DeepBlueSurvey]

Hi Justinas, thanks again for your great support. Generally speaking, Teltonika’s support is outstanding. Could you briefly let me know if the change you made will persist through a software update, and what exactly you did so that I can restore it myself if I have to reset the settings for some reason?

Thanks and have a good day

Thomas

[Justinas]

Greetings,

What resolved the issue was adding the following commands to to the /etc/mwan3/mwan3.user script

ip rule del pref 1201 2>/dev/null
ip rule del pref 1203 2>/dev/null

ip rule add pref 1201 fwmark 0x80100/0xff3f00 lookup 1
ip rule add pref 1203 fwmark 0x80300/0xff3f00 lookup 3

To edit the script, you can use the vi /etc/mwan3/mwan3.user command. Press i, to enter INSERT mode, and start editing file. Press Esc to exit INSERT mode. Press :wq and Enter. Changes will be saved.

These changes persist after a firmware update if you choose to keep settings while upgrading.

Furthermore, I have forwarded this issue to the R&D department, because a workaround should not be necessary for this to work properly.

Best Regards,
Justinas