Siemens LOGO! 0BA8 App 3.x: Resolving Remote Control Yellow Status Over NAT

Remote access to a Siemens LOGO! 8 (0BA8) via the LOGO! App 3.x typically works: the web server, I/O status, and variable memory (VM) view all populate correctly after NAT/port forwarding on TCP 8080. The failure mode reported in production deployments is different — the connection indicator turns green, status views load, but every element on the custom Control Page shows a persistent yellow status and will not toggle. This article documents the root cause, the supporting configuration in LOGO! Soft Comfort V8.x, and the exact recovery sequence that resolves the issue without firmware changes.

1. Problem Description and Failure Signature

Engineers deploying the LOGO! App 3.x against a 0BA8 module behind a NAT router see the following symptoms:

• The app establishes a TCP session over the forwarded port (default 8080) — session indicator is green.
• The VM Status, IO Status, and integrated Web Server screens render data without error.
• Custom Control Page widgets (toggle buttons, indicator lamps, text fields bound to VM addresses) display a yellow status instead of the normal idle gray or active green.
• Yellow elements cannot be operated; tapping them produces no toggle and no set/reset action is sent to the LOGO! program.
• Local LAN operation over the device's direct IP — without NAT — continues to work without modification.
• Wireshark capture of the public-IP connection shows the same GET / POST traffic to port 8080 as the LAN session; no packets are dropped at the firewall.

The asymmetry between LAN success and remote failure, combined with green session status, is the diagnostic signature of the configuration mismatch described in this article.

2. Affected System Versions and Components

Validate the affected module and toolchain before applying the resolution. The issue is observed on the following stack:

Older 0BA6 / 0BA7 modules do not support the LOGO! App 3.x Control Page and are out of scope. Newer 0BA8 firmware updates retain the same VM mapping behavior; the resolution applies to all 0BA8 firmware revisions.

3. Network Architecture and Port Forwarding

The 0BA8 exposes its web server and S7 communication on fixed TCP ports. The LOGO! App 3.x communicates exclusively over HTTP/HTTPS on the web-server port. The following diagram summarizes a typical remote-access topology:

3.1 Required TCP Port Forwarding

Forwarding only 8080 is sufficient for the LOGO! App 3.x Control Page. Port 10001 is referenced in third-party guidance but is not consistently used by the 3.x client; absence of traffic on 10001 in a packet capture is normal. Confirm that no upstream stateful firewall is performing deep packet inspection that strips the embedded JSON body of the Control Page PUT requests.

3.2 DNS, DDNS, and Certificate Considerations

If the app is configured with a hostname rather than a raw public IP, validate that:

• DDNS resolution returns the same public IP the router advertises.
• No CDN or reverse proxy terminates TLS in front of the LOGO! — the 0BA8 web server uses a self-signed certificate by default. Use HTTP or import a CA-signed certificate if HTTPS inspection is in the path.
• The router's hairpin NAT (NAT loopback) is enabled if you intend to test the public IP from inside the LAN.

4. Root Cause: Connection Profile and Control Page Bind Mismatch

The single underlying cause of the yellow Control Page status is a profile-to-binding mismatch:

1. The LOGO! App 3.x first creates a connection profile that stores the host (IP or hostname), port, and credentials used to authenticate with the LOGO! web server.
2. The Control Page is a separate object: it is built from one or more widgets, each bound to a specific VM address. When a widget is created, the app stores the connection profile identifier alongside the binding.
3. The web server routes read/write requests by comparing the request's source host field — derived from the connection profile that originated the session — to the host expected by each Control Page widget.
4. If a widget was authored while the profile was set to the LOGO!'s internal LAN IP, the widget carries that internal host reference. After the profile is edited to point at the public IP, the existing widgets still expect traffic on the original internal address. The web server returns the control response in a form the widget does not interpret as a valid state change, and the app renders the widget as yellow (unbound / unknown state).

Editing the host field of the existing profile is not sufficient — the app does not rewrite the host reference stored in each Control Page widget. Status views (VM/IO) succeed because they re-query the active profile on every refresh and do not cache a host reference per element.

5. LOGO! Soft Comfort V8.x VM Mapping Prerequisite

Before the LOGO! App can read or write any program variable, the variable must be exposed in the LOGO!'s Variable Memory (VM) map. This is configured in LOGO! Soft Comfort V8.x and downloaded to the module with the LSC program.

5.1 VM Address Ranges

5.2 Enabling Parameter VM Mapping

1. Open the project in LOGO! Soft Comfort V8.x.
2. From the menu, choose Tools → Parameter VM Mapping (also reachable via the toolbar icon in V8.1+).
3. In the mapping dialog, drag the desired program variables (inputs, outputs, flags, function-block outputs, analog values) from the left column into the VM column. Each mapping creates a VW entry that the app can address.
4. Click OK and download the program to the LOGO! (PC → LOGO!).
5. After download, the LOGO! Setup (Menu → Setup → VM Mapping on the device or via web server) shows the same addresses — confirm they match the Soft Comfort table.

Variables that are not mapped to VM cannot be controlled from the LOGO! App 3.x Control Page, even if the connection profile is correct. The widget will display yellow because the address does not exist in the LOGO! response.

6. Step-by-Step Resolution Procedure

The following procedure restores Control Page operation over a NAT-forwarded connection.

6.1 Prerequisites

• PC with LOGO! Soft Comfort V8.x installed and licensed (DEMO mode is acceptable for VM mapping edits).
• Ethernet or USB access to the LOGO! 0BA8 for program download.
• iOS / Android device with LOGO! App 3.x installed.
• Public IP (or DDNS hostname) of the NAT router, with TCP 8080 forwarded to the LOGO! LAN IP.

6.2 Procedure

1. Verify the LAN connection still works. Create or open a profile in the LOGO! App pointing at the LOGO!'s internal LAN IP, port 8080, with the configured web-server password. Confirm the Control Page elements turn green/gray (operational) on LAN. This baseline proves the LOGO! program, VM mapping, and credentials are correct.
2. Open LOGO! Soft Comfort V8.x. From Tools → Parameter VM Mapping, confirm every variable referenced by any Control Page widget has a corresponding VW mapping. Add any missing entries.
3. Download the updated LSC program to the LOGO!. Use PC → LOGO! transfer. Wait for the LOGO! to restart the user program (RUN LED solid green).
4. Enable web-server access if not already on. On the LOGO! (or via Soft Comfort's online view), open Setup → Web Server Access and set Access Control to On with a strong password. Note the configured port (default 8080).
5. Confirm the public IP is reachable on 8080. From an external network (cellular, off-site Wi-Fi), browse to http://<public-ip>:8080. The LOGO! web server login page should render.
6. Delete the existing connection profile in the LOGO! App. Do not edit the host field — long-press (iOS) or tap-and-hold (Android) the profile and choose Delete. This removes the host reference stored against the profile and all Control Page widget bindings.
7. Create a new connection profile with the public IP (or DDNS hostname), the forwarded port (8080), the configured web-server password, and a meaningful display name. Tap Connect — status indicator should turn green.
8. Recreate every Control Page widget from scratch. Do not import or duplicate an old Control Page. Add each widget manually: select the type (toggle button, indicator, text field), bind it to the corresponding VM address from the Soft Comfort mapping table, and save.
9. Validate each widget on the public-IP profile. Toggling a button should round-trip to the LOGO! and back; indicators should track I/O state in real time. A yellow widget indicates either a VM mapping omission (Section 5) or a widget that has not yet completed its first poll cycle.

7. Verification and Functional Testing

After the procedure, run the following checks before declaring the deployment complete:

1. Round-trip test: Toggle a Control Page button from the public-IP profile. Confirm with a second instance of LOGO! App 3.x on the LAN that the LOGO! digital output transitions. Read-back should reflect within one polling interval (typically 1–2 seconds).
2. VM Status cross-check: From the public-IP profile, open VM Status. Confirm every address used by a Control Page widget exists in the list with a non-zero, changing value when the corresponding program point is energized.
3. Access control verification: Reconnect from a third device with an incorrect password. The web server must reject the session; the LOGO! App should show a red status indicator.
4. Hairpin NAT test: From inside the LAN, open the app profile that uses the public IP. The connection should succeed (green) only if NAT loopback is configured; this is optional but useful to confirm the router is the only path used.
5. Sustained-state test: Leave the connection idle for 10 minutes. Many consumer NAT routers close the TCP mapping after idle timeout. If the connection drops, enable a keep-alive (the LOGO! App issues periodic status requests automatically, but aggressive router idle timers may still close the mapping — reduce the idle timeout on the router).

8. Access Control and Security Configuration

The LOGO! 0BA8 web server has two access modes that interact with the LOGO! App 3.x:

A persistently yellow Control Page is not a symptom of an access-control rejection — rejections present as red status or HTTP 401. If status views load but Control Page elements are yellow, the issue is the widget-to-profile host mismatch described in Section 4, not permissions.

8.1 Hardening Recommendations

• Place the LOGO! on an isolated VLAN or DMZ when exposing TCP 8080 to the internet.
• Replace the default web-server password with a 16+ character random string.
• If using HTTPS, import a CA-signed certificate into the LOGO! (V8.2+ supports certificate upload via Soft Comfort).
• Disable remote access at the router when maintenance is not active.

9. Troubleshooting Matrix

10. Field-Proven Tips

• Always create the connection profile first with the exact host string you intend to use in production, then build every Control Page against that profile. Changing the host later requires full re-creation.
• Document the Soft Comfort VM mapping in a project-side spreadsheet. Field engineers restoring a Control Page after a re-install rely on the mapping table to rebuild widgets without trial-and-error.
• If the LOGO! is behind a cellular router (4G/5G), the carrier often assigns CGN (carrier-grade NAT). In that case, expose the LOGO! through a VPN tunnel (WireGuard or IPsec) into the cellular router's network and connect the app to the VPN-side IP. Direct port-forwarding is not possible against CGN.
• Keep the LOGO! firmware current. Siemens releases periodic firmware updates that address web-server session handling, which can mask the symptoms described here.
• For multi-tenant deployments, segregate by Access Control password rather than by port — password rotation invalidates sessions without re-architecting the NAT rule.

11. Related Configuration: S7 Communication on Port 102

If the deployment also uses an S7 client (LOGO! Soft Comfort, a WinCC flexible / TIA Panel, or a third-party OPC UA gateway) to exchange data with the same LOGO! 0BA8 over the public IP, additionally forward TCP 102 and confirm Allow S7 Communication is enabled in the LOGO! Setup. S7 PUT/GET is required for any HMI panel that drives the Control Page concept into a higher-level SCADA view.