Resolving Siemens LOGO! 8 Web Server Log On Fail: 706 Error

Problem Statement

The Siemens LOGO! 8 base module (BM) and the LOGO! 8 with Ethernet expose a built-in web server used for remote monitoring, variable forcing, message-text editing, and program diagnostics. When the web server is reached through the Teltonika RUT240 cellular router's RMS (Remote Management System) HTTPS reverse-proxy tunnel, field engineers report that the login page renders correctly but every credential submission — correct or incorrect — returns Log On Fail: 706. The same credentials authenticate without error when the workstation is connected to the LOGO! on the local LAN. This article isolates the root cause, which is almost always a URL handling and session management mismatch between the LOGO! web server and the HTTPS reverse proxy, and provides field-validated remediation paths for installations on a single BM as well as for fleet deployments.

Affected Hardware and Firmware Versions

The LOGO! 8 web server is implemented inside the base module firmware; it is not a separate Siemens application. Behaviour described in this article applies to the entire LOGO! 8 family unless noted. Always confirm the firmware version from LOGO! menu > Diagnostics > IP > FW or from LOGO!Soft Comfort under Tools > Transfer > FW Version.

LOGO! Web Server Configuration Reference

Before troubleshooting, capture the current configuration so that any changes can be reversed. Open the project in LOGO!Soft Comfort V8.x, connect online, and inspect the parameters under Tools > Web Server Access. The conceptual enablement workflow for the related S7-1200 web server is described in the Siemens TIA Portal documentation: Enabling the Web Server reference, which uses the same enable/transfer/restart sequence that applies to LOGO!.

Root Cause Analysis of Error 706

The numeric error 706 is generated by the LOGO! web server when the login form submits a request that the firmware interprets as malformed or unsupported. The status code is part of the LOGO! HTTP error group 700–799, which covers session and authentication exceptions. The mapping used by firmware V1.08.04 is:

Error 706 specifically indicates that the POST payload intended for /logo_login.shtm arrived with a different URI, an unexpected Content-Type, or — most commonly — without the Referer header that the LOGO! login script requires for CSRF protection introduced in firmware V1.08.04.

The Teltonika RMS tunnel acts as an HTTPS reverse proxy: the user agent connects to rms.teltonika-networks.com on port 443, the request is forwarded over an outbound TLS tunnel to the RUT240, and the RUT240 in turn NATs the connection to the LOGO! at 192.168.1.7:80. Reverse proxies of this type do not always preserve the original Referer header, do not always forward POST bodies larger than an arbitrary threshold, and frequently rewrite the URL — stripping parameters such as !App-Language=1 from the path.

Diagnostic Procedure

Perform the following checks in order. Each test confirms or eliminates one hypothesis. Document the results in the commissioning log for handoff to operations.

1. Local baseline. From a workstation on the same subnet, browse to http://192.168.1.7/logo_login.shtm. Log in with the configured password. If this fails, the LOGO! itself is misconfigured — jump directly to Solution Path A.
2. Capture the remote request. From a workstation outside the LAN, install Wireshark on the operator PC or use browser Developer Tools (F12 → Network). Open the RMS-generated URL. Compare the headers of the GET request to logo_login.shtm with the headers of the GET from step 1. Look for a missing Referer, rewritten Host, or stripped query parameters.
3. Inspect the POST. Click Log In. Capture the POST request body and headers. The expected body is Password=<value> with Content-Type: application/x-www-form-urlencoded. If the POST arrives at the LOGO! as GET, with empty body, or with Content-Type: multipart/form-data, the RMS has re-encoded the form.
4. Test from a second remote method. Configure a WireGuard or OpenVPN client on the RUT240 (firmware RUT2_R_00.07.06 or newer supports WireGuard) and connect directly to the LOGO! on the tunnel address 10.0.0.7. If login succeeds over VPN but fails over RMS, the proxy is confirmed as the root cause.
5. Check firmware matrix. LOGO! 8.3 firmware V1.08.03 and later changed the login page flow; the 706 message text was introduced in V1.08.04. If the controller is below V1.08.02, upgrade first; if it is 8.0/8.1, 706 is not the actual code returned — it will be 703 or 704 instead.
6. Browser console review. Open F12 → Console on the failing page. Look for Mixed Content warnings (HTTPS page making HTTP requests) and CORS errors. Mixed content is auto-blocked by Chrome 86+ and will silently break the AJAX session.
7. RMS account tier. Confirm the RMS account is a paid tier. The free RMS tier limits concurrent tunnels to one and applies URL hashing that rewrites sub-paths; this is the single most common 706 trigger on consumer installations.

Solution Path A — Configure LOGO! Web Server Correctly

If the local LAN test in step 1 above failed, the LOGO! itself is rejecting the credentials. The 706 message can also be triggered when the password is set but empty, or when the password was changed in LOGO!Soft Comfort but not transferred to the device.

1. Open the project in LOGO!Soft Comfort V8.3 or V8.4 and select Tools > Web Server Access.
2. Tick Enable password protection and enter a non-empty password (8+ characters recommended; avoid the 4-digit PIN used in the LOGO! menu program protection — the two values must not collide).
3. Verify Allowed Clients is set to All (or contains the operator LAN subnet in CIDR notation, e.g. 192.168.1.0/24).
4. If the controller is 8.4 firmware and will be exposed via public internet, toggle HTTP off and leave only HTTPS on. Confirm that the operator browser will reach the LOGO! over HTTPS.
5. Click PC → LOGO! (Transfer) and confirm OK on the LOGO! display when prompted. The LOGO! will momentarily drop the Ethernet link during transfer.
6. Power-cycle the LOGO! to ensure the new web server settings take effect — V1.08.03 retains some settings in volatile memory until reboot.
7. Re-test from the LAN. Confirm that the dashboard refreshes VM/BM/AM values within 2 seconds of changing them in LOGO!Soft Comfort online mode.

The conceptual workflow is identical for the S7-1200 family, documented in the Siemens TIA Portal — Enabling the Web Server reference: enable, configure password, transfer, restart.

Solution Path B — Configure Teltonika RMS URL Forwarding

The RUT240 RMS exposes each device through a generated URL such as https://rms.teltonika-networks.com/<serial>/<token>/. The forwarding can be configured from RUT240 WebUI > Services > RMS > URL Forwarding or directly from the Teltonika RUT240 wiki. For the LOGO! web server, the following settings are mandatory:

If the RUT240 firmware is below RUT2_R_00.07.06, the RMS URL Forwarding cannot preserve POST bodies for non-Chrome browsers and will not forward Referer. Upgrade to RUT2_R_00.07.06.11 or newer before troubleshooting further. Firmware downloads and the changelog are available from the Teltonika RUT240 firmware documentation.

For HTTPS listeners (LOGO 8.3+): generate a self-signed certificate in LOGO!Soft Comfort Tools > Web Server > Certificate, export to PC, and import into the operator workstation's Trusted Root Certification Authorities store. RMS does not intercept TLS to the LOGO!; it tunnels TCP.

Solution Path C — Alternate Remote Access Topologies

When the RMS proxy cannot be made compatible with the LOGO! web server (common on locked-down corporate networks or when the operator client is on a Windows XP industrial workstation), use one of the following architectures instead.

C.1 WireGuard VPN on RUT240

Enable WireGuard on the RUT240 from Services > VPN > WireGuard. Create a peer for the operator workstation, assign the peer an address in 10.0.0.2/24, and add a static route 192.168.1.0/24 via the RUT240 WireGuard address. From the workstation, browse to http://192.168.1.7/logo_login.shtm directly — no URL rewriting, no 706, lowest latency, no RMS subscription cost.

C.2 OpenVPN client-to-site

Same concept using OpenVPN from Services > VPN > OpenVPN. Recommended when the operator client must run on Windows 7 / older industrial laptops. The RUT240 supports up to five concurrent OpenVPN clients on firmware ≥ RUT2_R_00.07.00. Use AES-256-GCM with tls-crypt-v2 for a balanced security/latency profile.

C.3 Direct port forwarding + IP allow-list

Configure a 1:1 NAT rule on the RUT240: Network > Firewall > Port Forwarding, external port 8080 (or 443), internal 192.168.1.7:80 (or 443). Restrict the source IP to the operator's static public address or ASN range. This is the lowest-overhead option but exposes the LOGO! directly to the internet — only viable when LOGO! 8.3+ HTTPS is mandatory and a deny-by-default firewall rule blocks all other sources.

C.4 SINEMA Remote Connect

For multi-site Siemens deployments, the SINEMA Remote Connect server (order number 6GK1720-1AH01-0BV0) brokers OpenVPN tunnels and integrates with LOGO! 8.4 via the Siemens security configuration tool. Use this when the LOGO! fleet exceeds ten units or when central certificate management is required.

Verification and Commissioning Checklist

After applying any of the remediation paths above, run the following checks from both inside and outside the LAN. Document results in the SAT (Site Acceptance Test) report.

Troubleshooting Matrix

Edge Cases and Field-Commissioning Notes

• LOGO! 8.0 vs 8.4 login flow. Pre-8.3 firmware does not require a Referer header; the 706 code was repurposed in 8.4 to indicate exactly this missing header. A controller returning 706 on 8.0 firmware has a different root cause (typically empty password — actually 703, but the user-visible text can vary by language pack).
• Concurrent sessions. LOGO! 8 firmware permits up to four simultaneous web sessions. The fifth concurrent login returns 702, but if a stale cookie from a closed tab remains in the controller's session table, the controller may incorrectly respond with 706 to the next valid login until the table times out (10 min default).
• Browser autofill conflict. Chrome's password manager can pre-fill the LOGO! password field before the page is fully rendered, causing the first submission to fire before the form's onsubmit handler attaches. Use Firefox ESR or disable autofill for the RMS domain.
• JavaScript disabled. The LOGO! web server login page is a static HTML form, but post-login navigation depends on JavaScript-driven AJAX. If JS is disabled in the browser, the user can log in but the dashboard never renders — this is not 706 but appears similar. Verify by enabling JS.
• Time zone mismatch. The LOGO! rejects login attempts where the controller's real-time clock has drifted more than ±24 hours from the operator workstation. Set the time via LOGO!Soft Comfort Tools > Set Clock or via NTP from the RUT240 LAN.
• LOGO! in STOP. If the LOGO! has stopped (red LED), the web server still serves the login page but every login attempt returns 706 with diagnostic buffer entry "Web auth: PLC in STOP". Recover the LOGO! to RUN first.
• SD card eject. LOGO! 8 uses the micro SD for web server logging when Tools > Web Server > Log to SD is enabled. If the SD card is removed mid-session, the next login returns 706. Re-insert the SD and retry.
• Hostname vs IP. Browsing to the LOGO! by hostname (e.g. http://logo8-plant1/logo_login.shtm) when DNS is not properly set on the operator workstation can produce 706 because the firmware expects the Host header to match the device IP or the configured hostname.
• Antivirus TLS interception. Corporate endpoint protection (Kaspersky, Sophos, CrowdStrike Falcon) sometimes terminates TLS at the agent and re-signs traffic. The RUT240 RMS sees the agent's certificate, not the browser's, and may strip the Referer. Exclude rms.teltonika-networks.com from TLS interception.
• LOGO! 8.4 firmware bug. Firmware V1.08.04.01 (released 2024-Q1) had a regression that returned 706 for passwords containing the + character. Upgrade to V1.08.04.02 or later.

Comparison With S7-1200 Web Server

Engineers familiar with the S7-1200 web server will recognise the same conceptual architecture: built-in HTTP/HTTPS server, password-based authentication, AJAX-driven dashboard. The differences that matter for 706-style errors are:

The S7-1200 web server enable workflow documented in the Siemens TIA Portal — Enabling the Web Server reference applies in concept to LOGO! 8: enable, set password, configure access list, transfer, restart.

Frequently Asked Questions