Troubleshooting OpenVPN Tunnel Failures on Siemens LOGO! CMR2020

When a PC client is configured to open an OpenVPN tunnel to a Siemens LOGO! CMR2020 cellular router, the most common failure mode is a tunnel that initiates, sends a few hundred bytes, and then stalls with zero bytes received. The OpenVPN GUI never reaches the CONNECTED state, the LOGO! 8 Base Module remains unreachable, and the WBM shows no incoming session in VPN > Status. This article walks through the diagnostic procedure, configuration checks, and resolution steps for that exact symptom on CMR2020 firmware V2.1.5.

1. Problem Description

The failure pattern is well-defined and reproducible against the documented configuration in the Siemens entry-level manual Setting up a Secure VPN Connection between a PC and LOGO! 8. The PC imports the vpnpeer.conf exported from the CMR WBM, replaces the DynDNS entry on line 4 with the SIM's public IP, saves the file as cmr.ovpn, and starts the OpenVPN 2.4.6 client. The GUI then shows traffic in the outbound direction only.

2. Affected Versions and Compatibility Matrix

Cross-check the CMR firmware and OpenVPN client versions before changing any settings. Each major CMR release regenerates the vpnpeer.conf with a slightly different default cipher and tls-cipher set, and a mismatched client cannot complete the TLS handshake.

Verify the active versions on the CMR by opening System > Overview in the WBM. The firmware, bootstrap, and mobile-module firmware values must each match a Siemens-released build. Open Siemens Industry Online Support (SIOS) and search for article 109769487 or for the 6BK1700 product family to obtain the released binary set.

3. Root Cause Analysis

The bytes-sent/zero-bytes-received pattern has four dominant root causes, listed in descending order of field frequency.

3.1 Carrier-side inbound filtering (CGNAT)

Many M2M data SIMs are issued from address pools that are private to the mobile operator (RFC 1918 or RFC 6598 / 100.64.0.0/10 carrier-grade NAT). The WBM WAN > Overview page reports the address the SIM has been given, but the operator never routes unsolicited inbound traffic to that address from the public Internet. The OpenVPN client therefore transmits packets that traverse the operator's gateway and are silently discarded before reaching the CMR.

3.2 MTU / fragmentation black-hole

Cellular PDP contexts typically enforce a maximum IP packet of 1428 bytes on LTE and as little as 1360 bytes on GPRS/EDGE. The OpenVPN default tun-mtu is 1500. The client sets the DF (don't fragment) bit on its UDP datagrams; the cellular PGW drops the oversized datagram without sending an ICMPv4 "Fragmentation Needed" back to the client (the "black-hole" effect). The client keeps retransmitting, but the CMR never sees the packet.

Field indicators:

• OpenVPN log shows repeating write UDP: message too long or need to fragment.
• Smaller payloads (e.g., ping -l 1300) succeed; payloads above ~1380 fail.
• Reducing tun-mtu to 1300 in the .ovpn makes the tunnel come up.

3.3 Cipher or TLS version mismatch

The vpnpeer.conf exported by CMR V2.1.5 pins cipher AES-256-CBC and tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256. OpenVPN 2.4.6 negotiates this set without issue. If the PC client has been silently upgraded to 2.5.x (Windows update, package manager), the new client may not include the legacy tls-cipher in its default proposal set. The TLS handshake fails: the client sends ClientHello, but the CMR cannot find a shared cipher and drops the packet. The client keeps retransmitting and the byte counters show the asymmetric pattern.

3.4 Routing or port error on the CMR

If the remote directive in line 4 of the vpnpeer.conf was not properly replaced — for example, the DynDNS hostname was left in place and a new line was added below it — only the first remote line is honoured. The client then tries to reach the original DynDNS hostname, not the SIM IP, and the CMR never sees the OpenVPN traffic.

4. Diagnostic Procedure

Execute the following checks in order. Stop at the first one that identifies a defect and apply the fix before re-testing.

1. Verify the public IP. From the PC, open https://api.ipify.org in a browser and compare the returned address with the value shown in CMR WBM WAN > Overview. The CMR-side value is the SIM-assigned address; the api.ipify.org value is the PC's NAT egress. They will not match — that is expected. Confirm the CMR value with the SIM provider that it is a routed public IPv4.
2. Probe UDP/1194. Run nc -vu <CMR-WAN-IP> 1194 (or nmap -sU -p 1194 <CMR-WAN-IP>). If the probe times out without an ICMP unreachable, carrier-side filtering is in effect.
3. Capture OpenVPN verbose logs. Add verb 5 to the cmr.ovpn and reconnect. Inspect the log for: TLS Error, no shared cipher, connection reset, or Fragmentation required.
4. Reduce tunnel MTU. Add tun-mtu 1300, mssfix 1200, and fragment 1300 to the client config and reconnect.
5. Inspect WBM VPN status. In VPN > Status on the CMR, observe whether any incoming connection is logged. If the list is empty during the client's CONNECTING phase, the packets are not reaching the CMR.
6. Read the system event log. On the CMR, open System > Event Log and filter for keywords: vpn, openvpn, tls, auth. A successful TLS handshake leaves a vpn-handshake-ok entry; a failure leaves auth-fail or tls-no-shared-cipher.
7. Confirm LAN reachability from a phone. Temporarily disable the PC firewall, tether a phone, and try the OpenVPN connection from the phone. If the phone establishes the tunnel, the problem is on the PC side; if the phone also fails, the problem is on the CMR or carrier side.

5. Configuration Verification

Edit cmr.ovpn and confirm each directive. The expected baseline against CMR firmware V2.1.5 with OpenVPN 2.4.6 is:

client
dev tun
proto udp
remote <SIM-PUBLIC-IP> 1194 udp
resolv-retry infinite
nobind

persist-key
persist-tun

remote-cert-tls server
cipher AES-256-CBC
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
tls-version-min 1.2

verb 5
mute 20

<ca>
-----BEGIN CERTIFICATE-----
[CA certificate content from CMR WBM]
-----END CERTIFICATE-----
</ca>

5.1 Replacing the DynDNS entry

The original vpnpeer.conf generated by the CMR contains a single remote directive in line 4 pointing to a DynDNS hostname. To use a static IP:

1. Open vpnpeer.conf in a UTF-8-capable editor (Notepad++, VS Code). Do not use Notepad or Word.
2. Replace the entire hostname on line 4 with the address shown in WAN > Overview.
3. Save the file as cmr.ovpn. The .ovpn extension is required for the OpenVPN GUI to recognise the profile.
4. Right-click the OpenVPN GUI tray icon and choose Import file, then select cmr.ovpn.

Common mistakes at this step:

• Leaving the original remote line in place and adding a second one below it — only the first remote is honoured.
• Trailing whitespace, invisible Unicode characters, or a missing udp keyword at the end of the remote line.
• Using a private IP shown on a local-only diagnostic page (192.168.x.x) instead of the WAN IP from the WBM.
• Re-exporting vpnpeer.conf from the CMR after editing the file — the export will overwrite the manual IP change.

6. Network Troubleshooting Steps

6.1 Confirm inbound reachability

From the PC command line:

ping -n 5 <CMR-PUBLIC-IP>
tracert -d -h 15 <CMR-PUBLIC-IP>

ICMP is commonly blocked at the cellular edge, so ping failure alone is not conclusive. If tracert terminates before reaching the operator's gateway (typically the last hop will be a private 10.x.x.x address), the SIM is behind CGNAT and inbound connections are not possible.

6.2 Reduce MTU for cellular

Add the following directives to cmr.ovpn:

tun-mtu 1300
mssfix 1200
fragment 1300

For very constrained GPRS links, reduce further to tun-mtu 1200 and mssfix 1100. The fragment directive tells OpenVPN to split outgoing UDP datagrams, which sidesteps the cellular PGW's silent-discard behaviour.

6.3 Switch to TCP if UDP is filtered

If the carrier blocks UDP/1194, switch the tunnel to TCP. Both sides must be changed:

proto tcp
remote <SIM-PUBLIC-IP> 1194 tcp

6.4 Bypass the local firewall

Temporarily disable the Windows Defender Firewall and any third-party security suite to confirm the OpenVPN traffic is not being blocked outbound. If disabling the firewall fixes the issue, create an explicit allow rule for %ProgramFiles%\OpenVPN\bin\openvpn.exe on UDP/1194 (or TCP/1194 if the protocol was switched).

7. OpenVPN Client Configuration Reference

The following table summarises the recommended directives for a PC-side cmr.ovpn against a CMR2020 running V2.1.5.

8. Interpreting OpenVPN Verbose Logs

With verb 5 set, the OpenVPN client writes a per-second trace to its log file. The following key lines identify the failure mode:

9. Workarounds Without Inbound Access

If the SIM is confirmed to be behind CGNAT, the CMR2020 cannot terminate inbound VPN traffic. Use one of the following alternatives.

1. LOGO! CMR as OpenVPN client (outbound). Configure the CMR in VPN > Connection with role "Client", point it at a hosted OpenVPN server (VPS with a public IP), and route the LOGO! 8 subnet through the tunnel. The PC then connects to the VPS-side tunnel endpoint.
2. Siemens SINEMA Remote Connect. Use the SINEMA RC server as a managed relay. The CMR2020 dials outbound to the SINEMA RC server; the PC dials inbound to the same server. SINEMA RC is licensed per CMR and per concurrent user. Confirm CMR firmware V2.1.5 is on the SINEMA RC compatibility list.
3. Tailscale or ZeroTier mesh. Install the agent on both the PC and the CMR (where firmware allows). The mesh traverses NAT using relay servers. Verify CMR firmware compatibility before commissioning.
4. SSH reverse tunnel. Run a script on the CMR (e.g., via the CMR's user-defined shell, where available, or from a PC on the same LAN) that opens ssh -R 1194:localhost:1194 [email protected]. The PC then connects to vps.example.com:1194 and is forwarded back to the LOGO! CMR.

All four options require only outbound cellular access (already confirmed working) and a reachable public endpoint.

10. Firmware and Module Update Procedure

If a known issue in CMR V2.1.5 is identified as the root cause, upgrade the firmware using the procedure below.

1. Download the current CMR2020 firmware package from Siemens Industry Online Support for the 6BK1700 product family.
2. Connect the PC directly to the CMR's LAN port (ETH1 on CMR2020, ETH2 on CMR2040).
3. Open https://192.168.0.1 in a browser. The default CMR LAN IP is 192.168.0.1/24.
4. Navigate to System > Firmware Update.
5. Select the downloaded .bin file and confirm the upload.
6. Wait for the CMR to reboot (3–5 minutes). Do not power-cycle during the update — an interrupted flash can render the device unbootable.
7. Re-export vpnpeer.conf from the WBM and re-import it on the PC. A firmware update may reset the VPN configuration, including certificates.

11. Verification Checklist

Confirm tunnel health with the following checks before declaring the issue resolved.

• OpenVPN GUI shows state CONNECTED, not CONNECTING or RECONNECTING.
• In the WBM VPN > Status page, the connected client shows a valid assigned IP (typically 10.8.0.2 for the default OpenVPN pool, or whatever the CMR is configured to issue).
• From the PC, ping <LOGO! 8 IP> over the tunnel returns replies. The LOGO! 8 default IP is 192.168.0.10 on a CMR-direct LAN.
• LOGO! Soft Comfort can connect to the LOGO! 8 across the tunnel for programming and online monitoring.
• The OpenVPN log on the PC contains the line Initialization Sequence Completed.
• The bytes-received counter increments steadily (not flat at zero).
• The tunnel survives a 60-second cellular link drop and reconnects automatically without manual intervention.

12. Quick-Reference Troubleshooting Matrix

FAQ