Remote access to the WebUI of the Teltonika router should only be enabled, especially with a public.IP, if the router is located at an external site without direct access. However, if the router is located at a local site with direct access, remote access should better be deactivated for security reasons. For this, please also note the FAQ Safety instructions to use a public.IP.

1. Activate remote access

WebUI
Enable remote HTTP access	The HTTP remote access to the router is enabled.
Enable remote HTTPS access	The HTTP remote access to the router is enabled.

2. Set the correct Source zone

Traffic Rule	Source zone
Enable_HTTP_WAN	From any host in wan	HTTP remote access to the router with the IP address of the SIM card or WAN port.
	From any host in vpn	HTTP remote access to the router with the mdex fixed.IP+/public via OpenVPN.
Enable_HTTPS_WAN	From any host in wan	HTTPS remote access to the router with the IP address of the SIM card or WAN port.
	From any host in vpn	HTTPS remote access to the router with the mdex fixed.IP+/public via OpenVPN possible.

3. Notes on using DMZ Configuration (forwarding all ports & protocols)

From firmware R_00.07.14.2 (& R_00.07.06.5)

Since version 7.06.5, the forwarding rules are automatically added with the required source zone, which is already set in the dmz_fw rule. This means that even with an mdex fixed.IP+/public via OpenVPN, it is no longer possible to lose remote access to the router by subsequently activating DMZ. Additional "workaround" scripts are no longer required since version 7.06.5.

1.2 DMZ and port forwarding

Firmware R_00.07.11 to R_00.07.14.1

It has been determined that remote access to the router is no longer possible from firmware R_00.07.11 to R_00.07.14.1 once the “Save & Apply” button under System -> Administration -> Access Control is pressed. This is a software error in firmware versions that has been fixed in version R_00.07.14.2. For affected routers, we recommend updating the firmware to the latest version. Without a firmware update, the following workarounds are available:

* Deactivate the DMZ and use individual port forwarding instead. * Add an additional port forwarding rule for remote access of the desired HTTPS port to the router LAN IP address. This allows the DMZ to be used in parallel.

From firmware R_00.07.06.5

Since version 7.06.5, the forwarding rules are automatically added with the required source zone, which is already set in the dmz_fw rule. This means that even with an mdex fixed.IP+/public via OpenVPN, it is no longer possible to lose remote access to the router by subsequently activating DMZ. Additional "workaround" scripts are no longer required since version 7.06.5.

1.2 DMZ and port forwarding

From firmware R_00.07.05

When using an mdex fixed.IP+/public via OpenVPN with active DMZ, there are a few things to note:

• For routers preconfigured by mdex for an mdex fixed.IP+/public via OpenVPN, the correct source zone "openvpn" is already set for all relevant rules.
• However, if "DMZ" is subsequently deactivated, all the above port forwarding rules are automatically deleted because they are no longer required.
• If "DMZ" is now reactivated, the above rules are automatically recreated, but all with the "wrong" source zone wan!
• In order for access via an mdex fixed.IP/public.IP via OpenVPN to work again, the source zones of these rules must be manually changed from wan openvpn. The correct sequence must be followed so that remote access to the router is not lost:
  
  1. first change the source zone of the port forwarding rules dmz_http, dmz_https, dmz_ssh and dmz_snmp to wan openvpn.
  2. the source zone of the last rule dmz_fw can then be changed from wan openvpn without losing remote access. ¹

¹ A script is implemented under System -> Maintenance -> Custom Scripts for security purposes, which automatically adjusts the "source zone" of the rules dmz_http, dmz_https, dmz_ssh and dmz_snmp when the router is rebooted from wan openvpn if only the source zone of the rule dmz_fw has been changed to "openvpn". This means that remote access to the router is possible again at the latest after the next router reboot if the rule dmz_fw was accidentally changed to "openvpn" first. This script is included in all routers from firmware 7.05 that have been preconfigured as mdex fixed.IP+ / public.IP via OpenVPN.

System -> Maintenance -> Custom ScriptsSystem -> Maintenance -> Custom Scripts

System ->#!/bin/sh
# mdex workaround: If the rule "dmz_fwd" is enabled and set to openvpn, the other fw rules "dmz_http", "dmz_https", "dmz_ssh" and "dmz_snmp" are also set to openvpn after the next router reboot. 

. /lib/functions.sh
dmz_src=""
src_updated=0
find_dmz_src() {
   local section="$1"
   local name="$(uci_get firewall "$section" "name")"
   if [ "$name" = "dmz_fw" ]; then
      dmz_src="$(uci_get firewall "$section" "src")"
   fi
}

update_dmz_fwds() {
   local section="$1"
   local name="$(uci_get firewall "$section" "name")"
   if [ "$name" = "dmz_http" ] || [ "$name" = "dmz_https" ] || [ "$name" = "dmz_snmp" ] || [ "$name" = "dmz_ssh" ]; then
      local src="$(uci_get firewall "$section" "src")"
      if [ "$src" != "$dmz_src" ]; then
         uci_set "firewall" "$section" "src" "$dmz_src"
         src_updated=1
      fi
   fi
}
config_load "firewall"
config_foreach find_dmz_src "redirect"
[ -z "$dmz_src" ] && exit 0
config_foreach update_dmz_fwds "redirect"
[ "$src_updated" -eq 0 ] && exit 0
uci_commit "firewall"
/etc/init.d/firewall reload

exit 0

From firmware R_00.07.03

Network -> Firewall -> Custom RulesNetwork -> Firewall -> Custom Rules

#!/bin/ash
###################################################################################################
# mdex workaround for router remote access, if dmz_fw is enabled:

## Check HTTP remote acccess:
HTTP_PORT="$(/sbin/uci get uhttpd.main.listen_http)"
HTTP_REMOTE_STATUS="$(/sbin/uci get uhttpd.main._httpWanAccess)"
if [ "${HTTP_REMOTE_STATUS}" == '1' ] ; then
iptables -t nat -A PREROUTING -i + -p tcp --dport ${HTTP_PORT} -j REDIRECT --to-port ${HTTP_PORT}
fi

## Check HTTPS remote acccess:
HTTPS_PORT="$(/sbin/uci get uhttpd.main.listen_https)"
HTTPS_REMOTE_STATUS="$(/sbin/uci get uhttpd.main._httpsWanAccess)"
if [ "${HTTPS_REMOTE_STATUS}" == '1' ] ; then
iptables -t nat -A PREROUTING -i + -p tcp --dport ${HTTPS_PORT} -j REDIRECT --to-port ${HTTPS_PORT}
fi

## Check SSH remote access
SSH_PORT="$(/sbin/uci get dropbear.@dropbear[0].Port)"
SSH_REMOTE_STATUS="$(/sbin/uci get dropbear.@dropbear[0]._sshWanAccess)"
if [ "${SSH_REMOTE_STATUS}" == '1' ] ; then
iptables -t nat -A PREROUTING -i + -p tcp --dport ${SSH_PORT} -j REDIRECT --to-port ${SSH_PORT}
fi
 
## Check SNMP remote access:
SNMP_PORT="$(/sbin/uci get snmpd.general.port)"
SNMP_REMOTE_STATUS="$(/sbin/uci get snmpd.general.remoteAccess)"
SNMP_PROTOCOL="$(/sbin/uci get snmpd.general.proto)"
if [ "${SNMP_REMOTE_STATUS}" == '1' ] ; then
iptables -t nat -A PREROUTING -i + -p ${SNMP_PROTOCOL} --dport ${SNMP_PORT} -j REDIRECT --to-port ${SNMP_PORT}
fi
###################################################################################################

Please note the following information:

• When using an mdex fixed.IP+ / public.IP via OpenVPN, the source zone of the rule Enable_HTTPS_WAN or Enable_HTTP_WAN must be set to openvpn under Network -> Firewall -> Traffic Rules!
• Subsequent changes to the router remote access, e.g. port changes, only take effect after the next router restart. If subsequent changes are made via remote access, there is a risk that remote access to the router will be lost until the next router restart!
• When updating the firmware from a "Legacy FW" to the current "Factory FW" (R_00.07.xx), the above-mentioned script is not automatically updated. If the "Keep all settings" option is activated, only the current configuration settings and existing rules according to Remote access to the router WebUI (legacy firmware) are applied.

Legacy firmware (up to version R_00.06.xx)

Port Forwarding Rule	Source zone
tlt_allow_remote_http_through_DMZ	From any host in wan	Remote HTTP access to the router with the IP address of the SIM card or WAN port
	From any host in vpn (Legacy FW) / openvpn (from R_00.07.xx)	HTTP remote access to the router with the mdex fixed.IP+/public via OpenVPN.
tlt_allow_remote_https_through_DMZ	From any host in wan	HTTPS remote access to the router with the IP address of the SIM card or WAN port
	From any host in vpn (Legacy FW) / openvpn (from R_00.07.xx)	HTTPS remote access to the router with the mdex fixed.IP+/public via OpenVPN.

When using an mdex fixed.IP+ via OpenVPN or mdex public.IP via OpenVPN, please note the information in the FAQ Important notes about using an mdex fixed.IP / public.IP via OpenVPN.

Problem with firmware RUT2XX_R_00.01.14.3 and RUT9XX_R_00.06.08.5

Due to a software bug in firmware RUT2XX_R_00. 01.14.3 and RUT9XX_R_00.06.08.5, the automatic rule tlt_allow_remote_http(s)_through_DMZ was incorrectly deleted as soon as the General Settings tab was opened and then closed again under Network -> Firewall. This meant that remote access to the router was no longer possible.
* As a workaround, all routers preconfigured by mdex in this configuration were delivered with an additional port forwarding rule Router Remote Access for remote access.

* If subsequent changes are made to the router LAN IP address or the router HTTP(S) port, this additional Router Remote Access rule must also be manually adjusted under Network -> Firewall in the Port Forwarding tab. If remote access is no longer desired, this Router Remote Access rule must also be deactivated or deleted.

This issue has been resolved with firmware RUT2XX_R_00.01.14.5 and RUT9XX_R_00.06.08.6, so that routers have since been delivered in this configuration without the additional Router Remote Access rule. Routers with older firmware versions should be updated.