Remote Access to Siemens LOGO! via Mobile Port Forward and VPN

Overview

The Siemens LOGO! 8 base module (6ED1052-xxxxx-0BA8 / 0BA3 / 0BA4) ships with an integrated Web server that exposes the LOGO! Web Editor (LWE) project on TCP port 80 by default. Once the server is reachable on the LAN, the question becomes: how do you reach the same Web UI - or the LOGO! mobile app - from a phone or tablet on a different network (4G/5G, hotel Wi-Fi, customer site)?

This reference covers three production-grade paths to expose the LOGO! outside the local network:

1. Direct port forwarding from the public WAN IP to the LOGO! IP, paired with Dynamic DNS for an unstable WAN address.
2. Outbound-only VPN using Siemens SINEMA RC with the LOGO! CMR, or a third-party WireGuard / OpenVPN tunnel on the office router.
3. HTTPS reverse proxy with mutual TLS for segmented networks (intermediate, used when only a DMZ host is exposed).

Direct port forwarding is the smallest change to a working LAN setup and is what the source troubleshooting thread is trying to achieve. We walk through every knob that has to be set, then explain why the same configuration succeeds from LAN yet fails from the WAN when the ISP uses CGNAT, when the firewall drops the inbound SYN, or when the LOGO! has not been told to listen on the non-default port.

Prerequisites

Before changing any router or LOGO! configuration, confirm the following items are in place. Each maps to a documented capability in the LOGO! system manual available on Siemens Industry Online Support.

• LOGO! 8 base module with Ethernet, order number 6ED1052-xxxxx-0BA8 (LOGO! 8.2) or later. The 0BA0, 0BA1, 0BA2 variants do not expose a Web server.
• LOGO! Soft Comfort 8.x installed on the engineering PC; the LWE project is generated inside this tool.
• Static IP on the LOGO! (e.g. 192.168.1.100/24). DHCP reservations work but a static address removes one variable from troubleshooting.
• Public WAN IP that is reachable from the outside (i.e. not behind CGNAT - see the verification section).
• Admin access to the office router / firewall for NAT and firewall rule changes.
• iOS 14+ or Android 8+ mobile device with the LOGO! App installed from the App Store / Play Store.

Identify Your LOGO! Hardware and Firmware

The Web server feature set differs by firmware generation. Match your hardware before configuring the port or user rights - older revisions do not support TLS and ship without user accounts, which matters the moment the device is reachable on the Internet.

The 0BA3 and 0BA4 hardware adds user administration and HTTPS. If you intend to expose the device to the public Internet, run 0BA4 firmware - the lack of TLS on older revisions means every command, including the password, is transmitted in plaintext.

Check the installed firmware from the LOGO! on-board display: Menu > Diagnostics > Software. The exact image name is LOGO! 8.4 xx-yy-zz style on 0BA4 hardware. The corresponding operating instructions are shipped as the LOGO! 8 system manual on Siemens Industry Online Support.

Configure the LOGO! Web Server (LWE)

The LWE project is built in LOGO! Soft Comfort and pushed to the base module over Ethernet. Two Web-server parameters must be set before any router NAT rule will work:

1. In LOGO! Soft Comfort: Tools > Transfer > Web Server Access. Tick Allow Web Server Access. This generates the logo.htm page that the device will serve.
2. On the LOGO! device: Menu > Settings > Network > Web Server Access. Enable the Web server and set the listen port. Leave port 80 for LAN-only deployments; for Internet exposure use a non-standard high port such as 8080 or 8443.
3. On 0BA3 / 0BA4 only: Menu > Settings > Security > Users and add an Admin account. Until a user is configured, the Web UI is read-only for safety.

The default URL once enabled is:

http://<LOGO_IP>:<port>/logo.htm
http://<LOGO_IP>:<port>/            (index page that links to logo.htm)

For HTTPS on 0BA4 firmware:

https://<LOGO_IP>:8443/logo.htm

The default self-signed certificate triggers a browser warning. Replace it with a CA-signed certificate through LOGO! Soft Comfort (Tools > Web Server > Certificate) or accept the warning only in trusted LANs.

Step-by-Step: Port Forwarding Setup

This is the configuration the original question is attempting. The flow is identical on consumer routers (Fritz!Box, TP-Link, Asus, MikroTik) - only the menu labels differ.

1. Confirm the LOGO! IP from the device menu. Record 192.168.1.100 (or your actual address).
2. Reserve the address. On the router DHCP page, bind the LOGO! MAC to 192.168.1.100. This prevents the address drifting after a power cycle.
3. Create the port-forward rule. Example for an Asus RT-AX86U:

   Service name:  LOGO_LWE
   Protocol:      TCP
   External port: 8080
   Internal port: 8080
   Internal IP:   192.168.1.100
   Source IP:     (blank - any)

4. Open the matching firewall pinhole. Consumer routers usually auto-open on NAT, but if a host firewall is in front of the LOGO! it must allow TCP 8080 inbound. The LOGO! itself runs no host firewall, so no extra rule is required.
5. Identify the public WAN IP. Visit the WAN IP display on the router's status page or check a service like ifconfig.me from a browser on the LAN. Record the address (e.g. 203.0.113.45).
6. Test from the LAN first. From a PC on the same LAN, open http://203.0.113.45:8080. If this fails, the port forward or hairpin NAT is misconfigured - do not yet test from the WAN.
7. Test from the WAN. Disable Wi-Fi on a phone, use cellular, and open http://203.0.113.45:8080.

If step 6 succeeds but step 7 fails, jump to the Troubleshooting Matrix. In the experience reported in the source thread, step 6 works (same LAN sees the UI) but step 7 (mobile on cellular) times out. That pattern almost always indicates one of the following:

• The WAN IP is private (100.64.0.0/10, 10.0.0.0/8, 172.16.0.0/12) - the ISP is using CGNAT.
• The ISP blocks inbound TCP 80, 8080, 443 by default (common on consumer broadband and most mobile carriers).
• The router's stateful firewall rejects the inbound SYN because it cannot trace the connection to an outbound flow.
• Hairpin NAT is disabled - this should not affect a phone on cellular, but it does break step 6 if tested via the WAN IP from LAN.

Detect CGNAT (Carrier-Grade NAT)

CGNAT is the single most common reason a correctly configured port forward fails when tested from the WAN. The customer premises equipment (CPE) receives a private address from the ISP and is double-NATed; no inbound connection from the public Internet can ever reach the CPE. Detection procedure:

1. On the office LAN, visit https://ifconfig.me from a browser and note the public IP returned.
2. On the office router, navigate to the WAN status page and note the IP assigned to the WAN interface.
3. If the two IPs differ, the ISP is using CGNAT. If they match, you have a public WAN IP and inbound ports should work (subject to ISP port blocking).

To bypass CGNAT without changing ISP, move to a VPN solution: SINEMA RC, WireGuard, or an outbound-only OpenVPN. These all initiate connections from the CPE side, so they are unaffected by inbound filtering or double NAT.

Dynamic DNS Configuration

Residential broadband typically rotates the public IP every 24-72 hours or on every modem reboot. Hard-coding the WAN IP into the LOGO! App only works until the lease rolls. Configure a Dynamic DNS client so a stable hostname always resolves to the current WAN IP.

Most consumer routers have built-in DDNS clients for providers such as No-IP, DynDNS, DuckDNS, and afraid.org. General flow:

1. Create an account at the provider and reserve a hostname (e.g. myplant.ddns.net).
2. On the router DDNS page, enter the account credentials and host.
3. Set the update interval to 60 seconds.
4. Verify from a phone on cellular: ping myplant.ddns.net should return the current public IP.

If the router does not support DDNS, run a client on a small always-on PC, a Raspberry Pi, or as a Docker container on a NAS. DuckDNS is well suited for this because it has a simple HTTPS update API:

curl -s "https://www.duckdns.org/update?domains=myplant&token=<TOKEN>&ip="

Run this every 5 minutes from cron. On the mobile side, the LOGO! App then points at myplant.duckdns.org:8080.

Mobile App Configuration and iOS Local Network Permission

The LOGO! App on iOS uses Apple's NSLocalNetworkUsageDescription and the com.apple.developer.networking.multicast entitlement to discover LOGO! devices on the local subnet via mDNS / Bonjour. Starting with iOS 14, every app must explicitly request Local Network access - the user must grant it the first time the app attempts to discover devices.

If the LOGO! App shows the device on Wi-Fi but refuses to connect, or never lists the LOGO! at all, the symptom is almost always the Local Network permission toggle. To verify and reset it:

1. Open iOS Settings.
2. Scroll to Privacy & Security.
3. Tap Local Network.
4. Toggle the LOGO! App entry to the on position. If it is already on, toggle it off and on once to force a re-prompt.

Apple documents this permission model at support.apple.com/en-us/102229. Android does not impose the same restriction; the LOGO! App on Android should connect without an additional permission.

For Internet access from the LOGO! App, enter the public hostname and port in the app's remote-access field rather than the LAN IP. The LOGO! App does not auto-fallover between LAN and WAN - you must configure both profiles and select the active one. Recommended profile setup:

VPN Alternative: SINEMA RC and WireGuard

Direct port forwarding exposes the LOGO! Web UI to anyone who can guess or scan the public IP and port. A VPN moves the LOGO! back into a private network and lets only authenticated clients reach it. VPN is also the only viable approach when the ISP runs CGNAT.

SINEMA RC (Siemens Remote Connect)

SINEMA RC is a Siemens-managed VPN server that terminates OpenVPN/IPSec tunnels from SOHO routers, SCALANCE industrial routers, and the LOGO! CMR (Communication Module Remote). The LOGO! CMR2020 / CMR2040 plug onto the LOGO! base module and bring outbound-only VPN connectivity - no router port forward is needed.

Topology: the CMR establishes an outbound TLS tunnel to the SINEMA RC server. The mobile user runs the SINEMA RC client (or any OpenVPN-compatible client) and connects to the server. The server bridges the two tunnels and the mobile user can address the LOGO! by its LAN IP (e.g. 192.168.1.100). From the mobile's perspective the LOGO! is on the office LAN - no port forwarding, no DDNS, no public exposure.

WireGuard / OpenVPN on the Office Router

If SINEMA RC is overkill, install WireGuard on an OpenWrt or MikroTik router and have the mobile run the official WireGuard app. Configuration summary for a Linux router running WireGuard:

# /etc/wireguard/wg0.conf on the office router
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <router_private_key>
# Allow forwarding to the LOGO! subnet
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -d 192.168.1.0/24 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.10.0.0/24 -d 192.168.1.0/24 -j MASQUERADE

[Peer]
# Phone
PublicKey = <phone_public_key>
AllowedIPs = 10.10.0.2/32

On the phone, install the WireGuard app, import a .conf containing the phone's private key and the router's public endpoint (<router_wan_ip>:51820), and bring the tunnel up. The phone then opens http://192.168.1.100:8080 exactly as it would on site. This is also CGNAT-safe because the tunnel is outbound-initiated.

Security Hardening

Default exposure is dangerous. Apply these minimum controls before any Internet-facing setup is left running.

• Upgrade the LOGO! to firmware 0BA4 with user administration enabled. Set a strong Admin password (>=12 chars, no service-account-style strings such as LOGO or admin).
• Use a non-standard external port (e.g. 51023) and disable the LOGO! default Web server port 80 if not required.
• Place the LOGO! behind a dedicated firewall, not the router's DMZ. The DMZ feature disables most NAT protection.
• Disable UPnP on the router - it overrides your explicit rule and can be exploited by malware on the LAN.
• Enable the router's Block WAN ping and the equivalent for the LOGO! port.
• Forward logs to a remote syslog so you see brute-force attempts against the LOGO! user account.
• Replace the LWE default page with a custom one that does not expose tag names with security implications (e.g. passwords, API keys).
• On 0BA4 hardware, enable HTTPS-only and reject HTTP on the listen port.

Verification and Test Plan

After configuration, run this checklist before declaring the deployment complete. Each line is a pass / fail test with a documented expected result.

1. From LAN, curl -I http://192.168.1.100:8080 returns HTTP/1.1 200 OK.
2. From LAN with public IP, curl -I http://203.0.113.45:8080 returns the same (hairpin NAT test).
3. From WAN (cellular), curl -I http://203.0.113.45:8080 returns HTTP/1.1 200 OK.
4. From WAN, the LOGO! App finds the device after entering the public hostname and port.
5. Reboot the router; within 2 minutes, the DDNS hostname resolves to the new WAN IP and remote access is restored.
6. Attempt telnet 203.0.113.45 22 from WAN - should be refused / timeout.
7. Run an external port scan (e.g. nmap -Pn from a cloud VM) against the public IP - only the forwarded port should be open.
8. From WAN, log in as a non-Admin user and verify write access is denied (0BA4 only).

Troubleshooting Matrix

Why the Source Configuration Fails

The original report states that http://<router WAN IP>:8080 succeeds from any LAN device (PC, mobile, tablet, wired or Wi-Fi) but fails from any device on a different network. Two conditions in the source confirm that the underlying problem is not the LOGO! configuration:

1. The router accepts the inbound packet and forwards it correctly to 192.168.1.100:8080 - the LAN test proves that the NAT and LWE are healthy.
2. The WAN-side test never reaches the LOGO! - the symptom is the connection refusing or timing out before the SYN reaches the router, which is consistent with CGNAT or ISP-level port filtering.

The shortest path to a working solution is therefore not a router setting change but a topology change: move the LOGO! behind a SINEMA RC client (LOGO! CMR) or install WireGuard on the office router and have the phone run the WireGuard client. Both approaches eliminate the inbound port forward entirely and are CGNAT-safe by design.

FAQ