I Enabled “Remote Access” for HTTP + HTTPS via the WebGUI (System > Administration > Access Control) on a RUT206 with and unchecked “Ignore private IPs on public interface” on both.
The WebGUI is now available on the WiFi interface but not on the WAN interface.
I did some testing and the following gets it to work, but it is not persistent and I do not know if it will interfere with other things.
fix: Firewall Zone Does Not Cover usb0
uci set firewall.3.device=‘usb0’
uci commit firewall
service firewall restart
fix: Asymmetric Routing on Reply Packets. arrives on usb0 but the reply goes out via eth0.2
IP=$(ip addr show usb0 | grep 'inet ’ | awk ‘{print $2}’ | cut -d/ -f1)
ip route add default dev usb0 src $IP table 10
ip rule add from $IP lookup 10 prio 100
but it seems to me that this should be handled autmaticaly in the firmware.
Disclaimer AI generated content ahead:
Bug Report: Teltonika RUT206 — Cellular WAN Remote Access Fails
| Field | Value |
|---|---|
| Date | 2026-05-29 |
| Device | Teltonika RUT206 |
| Firmware | RUTE_R_00.07.22.3 |
| Component | gsmd / netifd / firewall / policy routing |
1. Summary
Enabling “Remote Access” for HTTP/HTTPS via the WebGUI (System > Administration > Access Control) on a RUT206 with an active cellular LTE connection does not result in the WebGUI being reachable over the cellular WAN interface. The feature appears to work — toggles are on, firewall rules are created — but inbound connections on the cellular IP are silently dropped or not replied to.
2. Environment
| Setting | Value |
|---|---|
| WAN interface (cellular) | usb0 (USB/NDIS modem mode) |
| UCI interface name | mob1s1a1 |
| Cellular IP | <CELLULAR_IP> |
| Wired WAN | eth0.2 (<WIRED_WAN_IP>, metric 1) |
| Default route metric | eth0.2 metric 1 (preferred), usb0 metric 3 |
3. Steps to Reproduce
-
Insert SIM into RUT206. Confirm cellular connection is active.
-
Navigate to System > Administration > Access Control in the WebGUI.
-
Enable Remote Access for HTTP and HTTPS.
-
Save settings.
-
Attempt to reach the WebGUI from an external host using the cellular IP.
Expected: WebGUI is reachable on the cellular IP address.
Actual: Connection times out. No response is received.
4. Root Cause Analysis
Both issues share a single underlying cause: Teltonika’s gsmd daemon manages the cellular interface (usb0) outside of OpenWrt’s netifd subsystem, as evidenced by the static_mobile: true flag in ifstatus output:
$ ifstatus mob1s1a1
{
"l3_device": "usb0",
"ipv4-address": [], <-- netifd has no IP registered
"route": [], <-- netifd has no routes registered
"data": {
"static_mobile": true <-- gsmd owns this interface, not netifd
}
}
Because netifd is unaware of the interface IP, two subsystems that depend on it are never correctly initialised for the cellular interface.
4.1 Firewall Zone Does Not Cover usb0
The WAN firewall zone (firewall.3) lists mob1s1a1 in its network option. OpenWrt resolves network names to kernel device names via netifd. Because netifd has no IP registered for mob1s1a1, the firewall zone generates no iptables rule for usb0 in the INPUT chain:
# Expected rule — missing:
zone_wan_input all -- usb0 * 0.0.0.0/0 0.0.0.0/0
Inbound packets on usb0 therefore never reach the Enable_HTTP_WAN or Enable_HTTPS_WAN ACCEPT rules and are dropped by the default REJECT policy.
4.2 Asymmetric Routing on Reply Packets
Even if inbound packets pass the firewall, the router has two default routes:
default via <UPSTREAM_GW> dev eth0.2 metric 1 <-- preferred
default dev usb0 metric 3
Reply packets to inbound connections on usb0 are sent out via eth0.2 (lower metric). The remote client never receives the reply. No policy-based routing table is created for usb0 by the firmware when remote access is enabled.
5. Evidence
Packet capture confirms inbound SYN packets arrive on usb0 but no SYN-ACK is returned:
09:42:11.280595 IP <REMOTE_CLIENT> > <CELLULAR_IP>.80: Flags [S]
09:42:11.286493 IP <REMOTE_CLIENT> > <CELLULAR_IP>.80: Flags [S]
09:42:13.062602 IP <REMOTE_CLIENT> > <CELLULAR_IP>.80: Flags [S]
# No [S.] SYN-ACK replies visible
Firewall counters confirm zero packets reach the ACCEPT rules:
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 dpt:80 /* Enable_HTTP_WAN */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 dpt:443 /* Enable_HTTPS_WAN */
1.07K zone_wan_src_REJECT all -- * * ... /* default REJECT */
6. Manual Workarounds Required
Fix 1 — Add usb0 to WAN Firewall Zone
bash
uci set firewall.3.device='usb0'
uci commit firewall
service firewall restart
Fix 2 — Add Policy Routing for usb0 (Persistent via Hotplug)
bash
cat > /etc/hotplug.d/iface/99-usb0-policy-routing << 'EOF'
#!/bin/sh
if [ "$ACTION" = "ifup" ] && [ "$DEVICE" = "usb0" ]; then
IP=$(ip addr show usb0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
[ -z "$IP" ] && exit 0
grep -q usb0table /etc/iproute2/rt_tables || \
echo "10 usb0table" >> /etc/iproute2/rt_tables
ip route add default dev usb0 src $IP table 10
ip rule add from $IP lookup 10 prio 100
fi
if [ "$ACTION" = "ifdown" ] && [ "$DEVICE" = "usb0" ]; then
ip rule del lookup 10 prio 100 2>/dev/null
ip route flush table 10 2>/dev/null
fi
EOF
chmod +x /etc/hotplug.d/iface/99-usb0-policy-routing
7. Expected Firmware Fix
When the user enables Remote Access via the WebGUI, the firmware should automatically:
-
Register the cellular interface IP with netifd, or explicitly add the kernel device (
usb0) to the WAN firewall zone so that firewall rules apply correctly. -
Create a policy routing table for
usb0ensuring reply traffic returns via the correct interface, mirroring what netifd would set up automatically for a standard interface. -
Ensure both of the above survive interface reconnection and reboot.
The static_mobile: true design in gsmd is a valid architectural choice for fast SIM failover and modem management. However it requires gsmd or the remote access feature to compensate by performing the firewall and routing setup that netifd would otherwise handle automatically.