Fixing OPC UA Connection Failed in TIA V15.1 WinCC Professional

Symptom Overview

When configuring an OPC UA connection in TIA Portal V15.1 with WinCC Professional toward a Bosch Rexroth MLC-VPx (IndraLogic family) OPC UA server, the following two error indications appear during tag browsing in the engineering environment:

1. Tag list error: Connection failed: opc.tcp://192.168.2.1:4840
2. Status bar error: Cannot resolve IP address 192.168.2.1:4840. Try computer name instead

The same MLC-VPx OPC UA server responds correctly to a third-party client (Unified Automation UaExpert) and was working in a previous engineering environment under TIA Portal V14 with WinCC Advanced. This pattern is diagnostic: the network, the MLC firmware, and the OPC UA server are healthy. The fault is in the WinCC Professional V15.1 OPC UA channel driver and the URL/certificate matching it performs.

Root Cause Analysis

The Cannot resolve IP address error originates in the WinCC Professional OPC UA channel driver when the configured discovery URL contains a raw IP literal that does not match the server certificate. OPC UA endpoints are tied to the URL the server is bound to via the ApplicationUri field and the Subject Alternative Name (SAN) extension in the server certificate. When the MLC-VPx publishes urn:boschrexroth:de:MlcVpx:<serial> with endpoint opc.tcp://MLC-VPx.local:4840 but WinCC is told to use opc.tcp://192.168.2.1:4840, the URL does not match the certificate host. WinCC V15.1 refuses to enumerate endpoints in this state, while UaExpert falls back to a permissive mode that accepts the user-supplied URL.

Additional contributing factors specific to TIA V15.1 WinCC Professional:

• WinCC Professional V15.1 ships the OPC UA .NET stack from Siemens (file Siemens.Opc.Ua.Client.dll) which performs strict URI matching against the server certificate. The V14 stack was permissive and accepted URL mismatches with a warning only.
• TIA V15.1 does not provide a toggle to accept any URL. The only fix is to make the URL in the WinCC channel match the server certificate exactly.
• Self-signed certificates on the MLC must be present in the WinCC runtime trust store under TrustedPeerCertificates. Missing or untrusted server certs surface as BadCertificateUntrusted.
• DNS / NetBIOS name resolution on the engineering station and the WinCC Runtime PC must be able to resolve the hostname that the MLC certificate references.
• IndraWorks must have enabled the OPC UA server on the MLC-VPx and assigned a non-empty ApplicationUri in the server certificate.

Official references from Siemens Support:

• Siemens FAQ 109755215 - "Cannot resolve IP address" error during OPC UA communication in WinCC Professional.
• Siemens FAQ 63481236 - Basic FAQs on OPC UA communication with SIMATIC systems.
• Siemens FAQ 109479664 - Communication with OPC UA in TIA Portal.
• HMS Networks - Communicating to a Siemens WINCC SCADA via OPC UA documents the same TIA V15.1 / WinCC Professional OPC UA port configuration flow and the typical client-channel setup.

Pre-Diagnostics

Before changing the project, validate the server side with a neutral OPC UA client to confirm that the network path, port, and server certificate are correct. All commands below run on the engineering PC with the same network adapter that the WinCC Runtime will use.

1. Ping the MLC-VPx.

   ping 192.168.2.1

   Reply should be under 5 ms on a dedicated service network. Drop the test if ping fails and resolve the L2/L3 issue first.
2. Check TCP reachability of port 4840.

   Test-NetConnection -ComputerName 192.168.2.1 -Port 4840

   or with PowerShell 5.x, tnc 192.168.2.1 -port 4840. The result should show TcpTestSucceeded : True. With telnet 192.168.2.1 4840, the port should accept connections and the service should respond with an OPC UA Hello message on the first 8 bytes.
3. Browse with UaExpert.
   • Install Unified Automation UaExpert on the engineering PC.
   • Add a server at opc.tcp://192.168.2.1:4840.
   • Accept the server certificate on first connect.
   • Confirm that the endpoint list is returned and that tags can be dragged onto a Data Access view.
   • Note the ApplicationUri and endpoint URL shown in the UaExpert certificate dialog. These are the values that WinCC must use.
4. Export and inspect the MLC server certificate.
   • Export the OPC UA server certificate from the MLC-VPx using IndraWorks (System > OPC UA > Server > Export certificate). On the controller filesystem the certificate is at /opcua/cert/ServerCert.der.
   • Copy to the engineering PC and open in Windows (double-click).
   • Inspect the Subject Alternative Name field. Record the UniformResourceIdentifier value (e.g., urn:boschrexroth:de:MlcVpx:0815) and any DNS= entries.
   • Inspect Subject. The CN should be the controller's serial number or a meaningful label.

If UaExpert shows the endpoints and tags without error, the network and server are healthy. The fault is entirely in the WinCC Professional V15.1 OPC UA channel configuration.

TIA Portal V15.1 WinCC OPC UA Architecture

WinCC Professional V15.1 ships an OPC UA client channel that runs inside the WinCC Runtime. The channel DLL is loaded at RT start and maintains a long-lived OPC UA session to the configured server. Key architectural facts that drive the troubleshooting steps below:

The WinCC RT OPC UA channel opens exactly one OPC UA session per configured connection. If the engineering station is also the runtime station, TIA Portal and WinCC RT can both try to read the same server, but each uses its own session. The MLC-VPx default of 16 concurrent sessions is sufficient for typical SCADA topologies.

Step-by-Step Resolution

Step 1 - Add the MLC hostname to the Windows hosts file

WinCC V15.1 needs to resolve a hostname that matches the MLC server certificate. The fastest method is to add a static entry to the Windows hosts file of the engineering PC and of the WinCC Runtime PC (if they are different machines).

1. Open Notepad as Administrator.
2. Edit C:\Windows\System32\drivers\etc\hosts.
3. Add the line:

   192.168.2.1   MLC-VPx MLC-VPx.local

4. Save the file and close Notepad.

Verify with:

nslookup MLC-VPx
ping MLC-VPx

The nslookup command should return 192.168.2.1. The ping should resolve the hostname and reply.

Step 2 - Copy the MLC server certificate into the WinCC trust store

1. Export the MLC-VPx server certificate from IndraWorks as DER (.der) or Base64 (.cer).
2. On the engineering PC, copy the certificate file into the TIA trust list:

   C:\Program Files\Siemens\Automation\WinCC\bin\OPCUAServerTrustList\TrustedPeerCertificates\

3. On the runtime PC, copy the same file into:

   C:\Program Files\Siemens\Automation\WinCC RT\bin\OPCUAServerTrustList\TrustedPeerCertificates\

4. If a certificate was previously rejected, remove it from the RejectedCertificates folder of both locations.
5. Restart the WinCC Runtime service (or the engineering TIA Portal) so the trust list is reloaded.

Step 3 - Configure the WinCC Professional OPC UA channel

In TIA Portal V15.1:

1. Open the WinCC Professional project.
2. In the project tree, navigate to HMI tags > OPC UA > Connections.
3. Add a new OPC UA connection. In the connection wizard enter:

4. Click Browse on the connection. The error Cannot resolve IP address should disappear and the tag tree should populate.

Step 4 - Match the ApplicationUri

If browsing still fails, open the certificate again and confirm that the ApplicationUri matches the URL stem of the discovery server. WinCC requires the URL used in the connection to be either the same as the ApplicationUri or listed in the SAN. If the MLC certificate is bound to urn:boschrexroth:de:MlcVpx:<serial> and the URL is opc.tcp://MLC-VPx.local:4840, WinCC will reject the session unless the SAN contains the host portion.

Two options to resolve the mismatch:

• Re-issue the MLC server certificate with a SAN entry of type DNS=MLC-VPx.local via IndraWorks. Restart the OPC UA server on the MLC.
• Change the connection URL in WinCC to match the host portion of the ApplicationUri, e.g. opc.tcp://<serial>.local:4840, and add a hosts entry for that hostname. Less common in production but acceptable for diagnostics.

Step 5 - Allow OPC UA traffic in the Windows firewall

If using Security Policy = None and the MLC still does not respond, temporarily disable the Windows firewall on the engineering PC and the runtime PC to rule out the firewall rejecting the OPC UA handshake. OPC UA discovery (port 4840) and session messages must be allowed in both directions. For a permanent fix, create a Windows Firewall inbound rule:

New-NetFirewallRule -DisplayName "OPC UA MLC-VPx" -Direction Inbound -Protocol TCP -LocalPort 4840 -RemoteAddress 192.168.2.1 -Action Allow -Profile Any

Step 6 - Validate the runtime transfer

1. Compile the WinCC project in TIA Portal V15.1.
2. Transfer the project to the runtime (or start the local RT).
3. Start WinCC Runtime.
4. Open the tag simulation in the runtime. The runtime should now hold an open OPC UA session to the MLC-VPx.

Verification

Use these checks to confirm the fix is complete:

Bosch Rexroth MLC-VPx Server Specifics

The MLC-VPx is a variant of the Rexroth IndraLogic L40/L65 family with an integrated OPC UA server. The OPC UA server is enabled by default on port 4840 and auto-generates a self-signed server certificate on first startup. Important parameters (IndraWorks 14VRS and later):

If the MLC is configured with SecurityPolicy = Basic256Sha256 and a server certificate signed by an internal CA, both the CA root and the server certificate must be in the WinCC trust list. The TrustedPeerCertificates folder accepts both root and leaf certificates; the OPC UA client builds the chain from the leaf and the intermediate/root certificates it finds in the same folder.

Supported OPC UA security policies on MLC-VPx firmware >= 14VRS:

Diagnostic Matrix

Common Pitfalls and Edge Cases

1. Using an IP literal in a multi-NIC environment. The MLC-VPx may be reachable on two interfaces (e.g., service port and fieldbus). The OPC UA server may publish only the service port's hostname in its certificate. Always match the URL to the certificate, not to the interface you happen to be on.
2. WinCC RT and engineering on the same PC. When the engineering station is also the runtime, the OPC UA server and client may compete for port 4840. Stop the engineering-side OPC UA client session in TIA Portal (close the project) before starting the runtime to free the channel for the RT.
3. Mixed mode: WinCC V14 Advanced alongside V15.1 Professional. Both versions can co-exist on a PC. Make sure the V15.1 OPC UA channel uses the new stack, not a V14 stub. The V15.1 channel DLL is Siemens.Opc.Ua.Client.dll in the V15.1 install path; never replace it with a V14 version.
4. Subscription timeout on a slow link. The MLC default subscription lifetime of 600 s may be too long for diagnostic polling. Reduce to 30 s during commissioning. The WinCC RT default publishing interval is 1 s; align the MLC Min publishing interval accordingly.
5. Username/password authentication. Rexroth MLC supports username/password. The credentials must be provisioned in IndraWorks under the user management. WinCC Professional stores them in the connection configuration; do not commit plaintext passwords to a versioned TIA project. Use TIA Portal's project password protection.
6. TIA Portal V15.1 update rollup. Siemens released several updaters for V15.1 (up to Update 9). The OPC UA stack was updated in V15.1 Update 4 to fix several certificate handling edge cases. Update the TIA installation and the WinCC Runtime to the latest available V15.1 update before further troubleshooting.
7. Time skew on the WinCC Runtime PC. OPC UA secure channel negotiation fails if the clock skew between client and server exceeds the policy-defined tolerance (typically 5 minutes). Synchronize the WinCC RT PC against the same NTP source as the MLC-VPx.
8. Multiple TIA projects targeting the same MLC. Each TIA engineering project that browses the MLC adds a separate transient session. Avoid opening the same MLC from two engineering projects at the same time during commissioning.
9. Domain vs Workgroup trust. The MLC default user authentication is local to the controller. If WinCC RT and the MLC are in different Windows domains, Kerberos/NTLM authentication will not work; switch the MLC to local user authentication or to certificate-based X.509 authentication.

FAQ