Resolving WinCC Unified Web Control 'Refused to Connect' Errors

1. Problem Description

The WinCC Unified PC Runtime Browser Control (a.k.a. Web Control) reports https://<local-ip> refused to connect when an operator opens a screen containing a configured Web Control instance pointing at an internal device such as a vision inspection camera, a managed switch Web UI, or a remote I/O diagnostic page. The same URL loads normally when pasted into Chrome, Edge, or Firefox on the same engineering station. This asymmetry is the diagnostic signature of the problem documented in the Siemens operating manual Web Control (RT Unified) - WinCC Unified.

The symptom typically manifests as one of the following browser-rendered messages inside the Web Control surface:

• ERR_CONNECTION_REFUSED
• This site can't be reached. <ip> unexpectedly closed the connection.
• https://<ip> refused to connect
• A blank Web Control surface with a console Refused to display in a frame because an ancestor violates the same-origin policy or X-Frame-Options notice.

The control does not report a WinCC Unified diagnostic alarm; the failure is rendered inside the Chromium-derived embedded surface, which makes triage harder than a standard tag or connection alarm.

2. How the Web Control Embeds Remote Content

The Web Control in WinCC Unified PC Runtime is implemented as a managed embedded browser surface. Internally, the URL configured on the control is loaded into an iframe-style host document that lives inside the Runtime process. From the perspective of the target web server, the request:

1. Arrives with a Referer header pointing to a about:blank or Runtime-local origin, not to a top-level user-typed URL.
2. Is initiated from a non-interactive, secondary context (no address bar, no certificate viewer, no user gesture).
3. May be subject to the embedded browser's stricter handling of mixed content, self-signed certificates, and frame-ancestor policies.

Any of these three differences from a normal browser session can be the proximate cause of a refused connection. The fix depends on which layer is rejecting the request.

3. Root-Cause Matrix

4. Diagnosing X-Frame-Options and CSP Violations

The most common root cause for "loads in a browser, fails in Web Control" is the frame-ancestor policy of the target server. Modern web servers and IP cameras expose either:

• The legacy X-Frame-Options header (RFC 7034), values DENY, SAMEORIGIN, or ALLOW-FROM <uri>.
• The modern Content-Security-Policy header with a frame-ancestors directive.

To verify, capture the response headers from the camera while it is reachable from any PC on the same subnet:

1. Open a Command Prompt or PowerShell on a workstation that can reach the camera.
2. Run curl -I -k https://192.168.10.21 (substitute the camera IP). The -k flag skips certificate validation so you can see the headers regardless of TLS state.
3. Inspect the output for any of the following lines:

   X-Frame-Options: DENY
   X-Frame-Options: SAMEORIGIN
   Content-Security-Policy: frame-ancestors 'none'
   Content-Security-Policy: frame-ancestors 'self'

4. If any of these headers are present, the camera web server is explicitly forbidding embedding.

5. Diagnosing Network and TLS Layers

If no frame-ancestor restriction is present, the next check is transport-layer reachability from the Runtime host.

5.1 Confirm port reachability

On the WinCC Unified Runtime PC, open PowerShell and run:

Test-NetConnection -ComputerName 192.168.10.21 -Port 443
Test-NetConnection -ComputerName 192.168.10.21 -Port 80

If TcpTestSucceeded : False, the Web Control cannot succeed regardless of headers. The likely culprits are:

• The Runtime host and the camera are on different VLANs without an L3 route.
• A managed switch ACL blocks port 80/443 from the Runtime subnet.
• The camera HTTP server binds only to the management VLAN address.
• Windows Firewall on the Runtime host blocks outbound 443/80.

5.2 Confirm TLS chain acceptance

Run the following from the Runtime PC:

Invoke-WebRequest -Uri "https://192.168.10.21" -SkipCertificateCheck -Method Head

If this fails with RemoteCertificateNameMismatch or UntrustedRoot, the embedded Web Control surface will refuse the connection without offering a user override. Self-signed certificates on cameras are the single most common cause.

5.3 Verify hostname vs IP

Always configure the Web Control URL with the literal IP address unless the Runtime host can resolve the camera's hostname through its configured DNS search list. Mixed hostname/IP configurations are a frequent cause of intermittent refusals after DHCP renewal.

6. WinCC Unified Web Control Configuration

Per the Siemens documentation Web Control (RT Unified) - WinCC Unified, the Web Control in WinCC Unified PC Runtime is intentionally restricted. Notably, switching the control into a file-explorer-style navigation surface is not enabled; the control is meant for displaying fixed or tag-driven web content within a configured runtime screen.

Relevant configuration items that influence connectivity:

Verify each of these in the TIA Portal project and on the Runtime host:

1. Open the screen containing the Web Control in TIA Portal.
2. Select the Web Control instance and confirm the URL property. If a tag drives the URL, place a temporary cross-reference and confirm the tag value at runtime.
3. On the Runtime host, open the project runtime settings and verify that no system proxy is forced that excludes the camera subnet.

7. Resolutions by Root Cause

7.1 When X-Frame-Options or CSP is the cause

The camera vendor must be configured to allow embedding, or a reverse proxy in front of the camera must strip and rewrite the offending header. Direct configuration options depend on vendor capability:

• If the camera supports custom HTTP response headers (e.g., Axis, Basler, Cognex In-Sight Explorer-based cameras with HTTP config, Keyence CV-X/XG series with HTTP server config), change:

  X-Frame-Options: SAMEORIGIN   ->   (remove the header)
  # or
  Content-Security-Policy: ...; frame-ancestors *   (allow all ancestors)

• If the camera does not expose header configuration, terminate TLS at a reverse proxy on the Runtime host or a dedicated appliance, and remove or relax the header at the proxy.
• Do not modify the response headers on the production PLC/HMI subnet unless you have explicit vendor support, as some cameras use the same web server for firmware update workflows that should not be embeddable.

7.2 Reverse-proxy pattern with nginx (preferred for unsupported cameras)

On a small Linux or Windows host with nginx (e.g., 1.24.x or later), create a dedicated server block that proxies the camera and rewrites headers. Save as /etc/nginx/conf.d/camera-192-168-10-21.conf:

server {
    listen 8443 ssl;
    server_name _;

    ssl_certificate     /etc/nginx/ssl/runtime-host.crt;
    ssl_certificate_key /etc/nginx/ssl/runtime-host.key;

    # Strip the legacy frame restriction and rewrite CSP frame-ancestors.
    proxy_hide_header X-Frame-Options;
    proxy_hide_header Content-Security-Policy;

    location / {
        proxy_pass         https://192.168.10.21;
        proxy_ssl_verify   off;       # accept self-signed camera cert
        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Then point the Web Control URL at https://<runtime-host>:8443. The proxy delivers the camera's content under a WinCC-trusted TLS context and removes the embedding restriction. Restart the Runtime screen to force the Web Control to fetch the new URL.

7.3 When TLS / self-signed certificates are the cause

1. Install the camera vendor's CA certificate into the Windows certificate store under Trusted Root Certification Authorities on the Runtime host. This must be performed under the same user account that starts the WinCC Unified Runtime service.
2. If the camera does not expose a CA and uses only self-signed leaf certificates, deploy a small internal CA on the OT network and re-issue the camera certificate, then repeat step 1.
3. If neither is acceptable, terminate TLS at the reverse proxy in section 7.2 and use a corporate-issued proxy certificate.

7.4 When network segmentation is the cause

1. Verify that the Runtime host can reach the camera by IP. Use Test-NetConnection as in section 5.1.
2. If a firewall is between the Runtime host and the camera, open the minimum required ports (typically TCP 80 and 443) from the Runtime host IP to the camera IP only. Avoid opening UDP ranges.
3. If the camera only exposes its web UI on a management VLAN, configure a VLAN-tagged secondary interface on the Runtime host or place a small L3 hop on the OT network that can route between the Runtime VLAN and the camera management VLAN.

7.5 When authentication blocks embedding

Many cameras use HTTP Basic or Digest auth. The Web Control's iframe surface cannot present a login dialog because it lacks a top-level address bar. Use one of:

• Configure the camera for a long-lived session cookie, then preload the cookie via a startup script on the Runtime host that runs before WinCC Unified Runtime starts.
• Front the camera with the reverse proxy in section 7.2 and disable auth at the proxy after validating the source IP.
• Use a vendor that supports token-based auth passed via URL parameter.

8. Verifying the Fix

1. Save and recompile the TIA Portal project. Download to the Runtime PC.
2. Start the Runtime. Navigate to the screen containing the Web Control.
3. Confirm that the camera UI renders inside the control. If a login prompt appears, the request reached the camera but auth is required (see 7.5).
4. Open Windows Event Viewer on the Runtime host, navigate to Applications and Services Log > Microsoft > Windows > WinCC Unified if present, and confirm there are no connection-related errors logged at the same timestamp.
5. From a separate engineering PC, open a browser DevTools session (F12 → Network tab) and visit the same URL. Compare the response headers to what the Runtime sees by running:

   curl -I -k https://192.168.10.21 | findstr /i "frame content-security"

   The two should match. If the standalone browser sees no headers and the Runtime still refuses, capture a network trace on the Runtime host with Wireshark to confirm whether the SYN is answered.

6. Cycle the Runtime screen multiple times to verify the connection is stable across reloads.

9. Long-Term Hardening

• Document every Web Control target URL and the corresponding camera IP, port, certificate chain, and frame-ancestor policy in the project's network register.
• Standardize on a reverse-proxy pattern with internal CA-signed certificates for all cameras surfaced in WinCC Unified. This removes per-camera header configuration from the deployment checklist.
• Disable unnecessary features on the Web Control (navigation, scrollbars, zoom) to reduce the attack surface exposed inside the Runtime.
• During commissioning, capture a baseline curl -I from the Runtime host for every Web Control target and store it alongside the project archive. This makes regressions caused by vendor firmware updates traceable to a single header change.
• When the camera vendor publishes a firmware update, retest all Web Control screens in a staging environment before pushing to production. Firmware updates are the most common cause of previously working Web Controls suddenly refusing to connect.

10. Quick Reference: Decision Flow

START
  |
  +-- Test-NetConnection camera_ip 443 -> FAIL --> Fix network/VLAN/firewall
  |
  +-- curl -I -k camera_ip -> contains X-Frame-Options or CSP frame-ancestors?
  |       |
  |       YES --> Strip headers at reverse proxy OR change camera config
  |       |
  |       NO
  |       |
  +-- Standalone browser warns about cert?
  |       |
  |       YES --> Install camera CA OR proxy with corporate cert
  |       |
  |       NO
  |       |
  +-- Camera returns 401/407 to embedded requests?
          |
          YES --> Pre-auth via cookie OR disable auth at proxy
          |
          NO  --> Capture Wireshark trace, escalate to vendor

11. Frequently Asked Questions