Siemens IOT2050 Node-RED Web Access: Troubleshooting Guide

Problem Description

The Siemens IOT2050 industrial IoT gateway is delivered with a Yocto Linux-based Example Image that bundles Node-RED as a pre-installed flow-based development tool. In a typical commissioning scenario, an engineer connects the IOT2050's Ethernet port (X2 P1 or P2) to a local router, assigns a static IP address (commonly 192.168.200.10), and expects the Node-RED editor to be reachable from a separate engineering notebook at http://192.168.200.10:1880.

Symptom: Node-RED starts on the IOT2050 and logs the following message on the serial console or SSH terminal:

When the user navigates to http://192.168.200.10:1880 from a PC connected to the same router (via Wi-Fi or Ethernet), the browser times out, returns ERR_CONNECTION_TIMED_OUT, or This site can't be reached. The PC's own local Node-RED instance at http://localhost:1880 continues to work normally, which confirms that the browser, the Node-RED runtime, and the JavaScript engine are not the problem — the network path between them is.

Root Cause Analysis

The 127.0.0.1 vs. 0.0.0.0 distinction is the source of most of the confusion in the field. Node-RED's uiHost setting in settings.js controls the bind address. The default in Node-RED 1.x and 2.x is 0.0.0.0, which makes the editor reachable on every interface (loopback, Ethernet, Wi-Fi, virtual bridges). The startup banner still prints http://127.0.0.1:1880/ because the editor builds the URL from the loopback address, not the bind address — this is purely cosmetic.

On the IOT2050 with Example Image v1.0.2 and later revisions, the typical causes of a "Node-RED starts but cannot be reached remotely" symptom are:

Items 1, 2, and 3 together account for roughly 80% of all field reports. Item 4 is rare unless an integrator has modified the shipped configuration. Item 5 produces a symptom that looks identical to the others and must be ruled out before changing any IOT2050 configuration.

Diagnostic Procedure

Execute the following steps in order. Each step is independent of the next; stop as soon as the editor becomes reachable. SSH access to the IOT2050 is required — establish it either via the X1 service port (192.168.200.10 default), via the routed LAN interface, or via the micro-USB serial console documented in the IOT2050 Equipment Manual on the Siemens Industry Online Support portal.

1. Confirm the IOT2050 LAN IP address

   SSH into the IOT2050 and run:

   ip -4 addr show
   ip route
   nmcli -t -f IP4.ADDRESS,IP4.GATEWAY,IP4.ROUTE device show eth0
   nmcli -t -f IP4.ADDRESS,IP4.GATEWAY,IP4.ROUTE device show eth1

   The output reveals which physical port (X1, X2 P1, or X2 P2) is associated with the 192.168.200.10 address. If 192.168.200.10 is on eth1 but the Ethernet cable is in X2 P1, the address is unreachable on the wired link and the browser will fail with a timeout.

2. Verify the service is bound to a routable address

   From the IOT2050 shell:

   ss -tlnp | grep -E '1880|node'
   sudo lsof -iTCP:1880 -sTCP:LISTEN 2>/dev/null

   Expected output: a row where the Local Address:Port column reads 0.0.0.0:1880 or *:1880. If you see 127.0.0.1:1880, Node-RED is bound to loopback only — proceed to the "Re-binding Node-RED" section.

3. Ping the IOT2050 from the engineering PC

   From the Windows command prompt or Linux terminal:

   ping 192.168.200.10
   tracert 192.168.200.10   (Windows)
   traceroute 192.168.200.10   (Linux)

   If the ping fails with Destination host unreachable or Request timed out, the path is broken before Node-RED is consulted. Inspect subnet masks, the router's DHCP range, and any wireless isolation (AP/Client isolation) feature on the Wi-Fi access point.

4. Probe TCP/1880 directly from the PC

   Open a PowerShell, Telnet, or netcat session to confirm port reachability independently of the browser:

   Test-NetConnection 192.168.200.10 -Port 1880   (PowerShell)
   nc -vz 192.168.200.10 1880                       (Linux/macOS)
   telnet 192.168.200.10 1880                        (legacy)

   TcpTestSucceeded: True (PowerShell) or succeeded (nc) means the path is open to the Node-RED process. A failure at this step points to a firewall, AP isolation, or wrong-IP issue — not to Node-RED itself.

5. Inspect the IOT2050 host firewall

   On the IOT2050:

   sudo iptables -L INPUT -n -v
   sudo iptables -L -n -v --line-numbers
   sudo nft list ruleset 2>/dev/null
   sudo ufw status 2>/dev/null
   sudo firewall-cmd --list-all 2>/dev/null

   The Example Image ships with iptables rules generated by iptables-services and with no listening services blocked by default. Custom deployments, AppArmor profiles, or SELinux policies on derivative images can drop inbound traffic to TCP/1880.

6. Inspect Node-RED settings.js

   Locate and review the active settings file:

   sudo find / -name 'settings.js' 2>/dev/null | xargs grep -l 'uiHost\|uiPort' 2>/dev/null
   cat /etc/node-red/settings.js 2>/dev/null | grep -A2 -E 'uiHost|uiPort'
   cat /var/lib/node-red/settings.js 2>/dev/null | grep -A2 -E 'uiHost|uiPort'

   Any non-default value for uiHost (especially 127.0.0.1, localhost, or a specific IP) is the smoking gun.

7. Cross-check the startup banner for clues

   Restart Node-RED with verbose logging and capture the full banner:

   sudo systemctl stop node-red
   node-red --settings /etc/node-red/settings.js 2>&1 | tee /tmp/nr.log

   The "Server now running at ..." line is cosmetic. What matters are any EADDRINUSE, EACCES, or Error: listen EADDRNOTAVAIL lines that follow.

Network Configuration on the IOT2050

The IOT2050 Example Image uses NetworkManager for interface configuration. The shipped configuration assigns 192.168.200.10/24 to the X1 service port with no default gateway, and leaves the X2 ports (P1 and P2) configured as DHCP clients on a 192.168.1.0/24 fallback profile. When the device is wired to a router via the X2 port, the DHCP profile takes over and 192.168.200.10 is no longer active on any reachable interface — the user types an address that the IOT2050 is no longer listening on.

To force a static LAN address on the X2 P1 port (typical setup for a router with a 192.168.200.0/24 subnet):

sudo nmcli connection add type ethernet \
    con-name iot2050-lan \
    ifname eth0 \
    ipv4.method manual \
    ipv4.addresses 192.168.200.10/24 \
    ipv4.gateway 192.168.200.1 \
    ipv4.dns 192.168.200.1
sudo nmcli connection up iot2050-lan

Replace eth0 with eth1 if the cable is plugged into the second X2 port. Confirm the new state with ip -4 addr show and ip route before continuing. The Siemens IOT2050 product support page documents the physical port numbering (X1, X2 P1, X2 P2) and the default NetworkManager profiles shipped with each Example Image revision.

Re-binding Node-RED to All Interfaces

If the diagnostic above shows Node-RED listening on 127.0.0.1:1880 only, edit the active settings.js. Node-RED's official configuration reference states that uiHost defaults to 0.0.0.0 and uiPort defaults to 1880 unless explicitly overridden.

Procedure (verified against the Node-RED runtime configuration reference):

1. Open the active settings file: sudo nano /etc/node-red/settings.js (or the path reported by node-red --help).
2. Locate the line: //uiHost: "127.0.0.1",
3. Uncomment and set it to: uiHost: "0.0.0.0",
4. Confirm uiPort: 1880, is present and uncommented.
5. Save and restart the service: sudo systemctl restart node-red
6. Verify the bind address: ss -tlnp | grep 1880

If the value was already 0.0.0.0 and the bind address still shows 127.0.0.1, the Node-RED process is reading a different settings file. Use ps -ef | grep node-red to inspect the exact --userDir and --settings arguments and trace back to the file actually in use. The IOT2050 Example Image typically deploys the configuration under /var/lib/node-red/ rather than /etc/node-red/ — confirm with systemctl cat node-red.

Reference: Node-RED Runtime Configuration documents the uiHost, uiPort, and https settings, and explains how the startup banner URL is constructed independently of the bind address.

Opening the IOT2050 Host Firewall

If the IOT2050 is reachable by ping but TCP/1880 is filtered, add an explicit iptables rule. The Example Image uses iptables as the default front end; nftables is available but not configured out of the box.

sudo iptables -I INPUT -p tcp --dport 1880 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo netfilter-persistent save   # or: sudo iptables-save > /etc/iptables/rules.v4

Reload the rules and verify with sudo iptables -L INPUT -n -v. The new line should show a non-zero packet count after the next attempt from the PC. For long-term persistence, integrate the rule into the image's /etc/rc.local or a NetworkManager dispatcher script under /etc/NetworkManager/dispatcher.d/.

For a narrower rule that restricts Node-RED access to the engineering subnet only:

sudo iptables -I INPUT -p tcp -s 192.168.200.0/24 --dport 1880 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 1880 -j DROP

For systemd-managed services that need to bind to a privileged port, also confirm the AmbientCapabilities=CAP_NET_BIND_SERVICE directive is present in the unit file if port 1880 is remapped below 1024.

Securing the Node-RED Editor

The default Node-RED installation is not designed for direct exposure to the Internet or even to an untrusted LAN segment. Once the editor is reachable on the engineering subnet, harden it before granting broader access. The official Securing Node-RED reference is the authoritative checklist.

1. Set a strong admin password by configuring adminAuth in settings.js with a bcrypt hash of the password (the node-red-admin hash-pw command generates the hash).
2. Enable HTTPS with the https configuration block to encrypt the editor and any HTTP-In nodes serving credentials. Reference: Securing Node-RED.
3. Restrict source IPs by combining the iptables INPUT rules above with -s 192.168.200.0/24 (or the engineering subnet).
4. Disable the editor entirely once the flows are stable by setting disableEditor: true in settings.js — the flows continue to run while the dashboard and HTTP endpoints remain available.
5. Enable httpNodeAuth and httpStaticAuth to protect HTTP-In / HTTP-Response nodes from anonymous POSTs.
6. If the IOT2050 is reachable from the Internet via port forwarding, terminate the connection at a reverse proxy (nginx, Caddy) and apply rate limiting plus fail2ban in front of the Node-RED process.

Verification

After applying the corrective action, run the full verification sequence:

1. From the IOT2050: ss -tlnp | grep 1880 shows 0.0.0.0:1880 (or *:1880).
2. From the PC: ping 192.168.200.10 returns replies with sub-millisecond latency on a wired link.
3. From the PC: Test-NetConnection 192.168.200.10 -Port 1880 returns TcpTestSucceeded: True.
4. From the PC browser: http://192.168.200.10:1880 loads the Node-RED editor within 2 seconds.
5. From the PC browser: http://192.168.200.10:1880/flows shows the currently deployed flows.
6. From a second device on the same subnet: repeat steps 3–5 to confirm the service is not bound to a single MAC/IP pair.
7. From the IOT2050 service log: sudo journalctl -u node-red -n 50 shows no EADDRINUSE, EACCES, or TypeError entries.

If the browser still fails after all seven steps, capture the Node-RED process output with NODE_OPTIONS="--inspect" node-red and the PC browser's HAR file for further analysis. The official Node-RED local running guide covers the standard startup parameters and their interaction with systemd, including --userDir, --settings, and --safe-mode.

Troubleshooting Matrix

Frequently Asked Questions