Resolving LHTTP DNS Issues on SIMATIC Open Controller

1. Problem Statement

When using the LHTTP library on a SIMATIC ET 200SP Open Controller running SoftwarePLC, name-based HTTP requests to cloud APIs fail with DNS timeout errors while direct IP-based requests succeed. The failure is caused by subnet separation between the SoftwarePLC virtual NIC (typically 192.168.x.x) and the Windows PC system NIC that owns the physical uplink to the corporate network or internet (typically 10.108.x.x or similar).

The PLC's IP stack cannot reach the DNS server configured for the Windows side because:

• The SoftwarePLC interface sits on an isolated internal subnet.
• The PC system interface sits on the plant network with default gateway and DNS settings.
• The hwID := "Local~PC_communications_interface" string bridges outbound connections from the PLC into the Windows network stack, but only for IP-routed traffic.
• DNS resolution requires that the DNS server IP be reachable through the PLC's routing table; if no router is defined for the PLC's subnet, or the DNS server address lies outside the PLC's local subnet, the resolver cannot issue a query.

2. Affected Products and Firmware

The LHTTP library ships as a global library in the Siemens LHTTP Application Example and is referenced inside the project via LibController / LibData function blocks such as LHTTP_Client.

3. Network Architecture on the Open Controller

The ET 200SP Open Controller runs two parallel operating systems on one device:

1. SoftwarePLC runtime (Windows / RTX): Executes the S7-1500 PLC program. The virtual NIC bound to the PLC program is typically 192.168.1.1 / 255.255.255.0.
2. PC system (Windows): A standard Windows installation that owns the physical Ethernet ports (X1, X2) of the device. This NIC has the real plant IP, default gateway, and DNS servers.

The two systems communicate through a Hyper-V virtual switch and the SIMATIC RT-VMM Network Adapter. The hwID parameter in the TCON function block selects which interface the TCP connection originates from:

When the PLC program issues an HTTP request through LHTTP, the underlying TCON binds the socket to the chosen hwID. The TCP handshake is relayed through Windows, so IP-routed traffic flows normally. DNS resolution, however, is performed by the PLC runtime itself, which means the DNS server IP must be reachable from the SoftwarePLC stack — not just from Windows.

4. Root Cause: DNS Server Outside the PLC Subnet

The TIA Portal device configuration under Properties > PROFINET interface [X1] > IPv4 addresses provides three fields:

• IP address
• Subnet mask
• Router (default gateway)

A separate section under Properties > DNS server accepts up to two DNS server IPv4 addresses. The PLC will only forward DNS queries to an address that is:

1. On the same subnet as the PLC interface, OR
2. Reachable through the configured router address.

If neither condition is met, DNS resolution fails with a TCP RST / ICMP unreachable equivalent on the PLC side, and the LHTTP call returns an error.

In the reported case:

• PLC subnet: 192.168.1.0/24
• Windows NIC: 10.108.x.x / 24 with DNS servers in the 10.108.x.x range
• No router configured in TIA Portal for the PLC interface

Direct IP connections still succeed because the Windows stack performs the routing once the TCP connection crosses the PC_communications_interface boundary — the PLC never has to resolve anything. Hostname connections fail because the PLC's resolver cannot reach 10.108.x.x directly and has no default route.

5. Solution Path A — Configure a Router in TIA Portal

The recommended fix is to add a router address in the PLC interface properties so that the PLC's resolver can forward DNS queries outside the local subnet.

Step-by-step

1. Open the TIA Portal project containing the SoftwarePLC.
2. Navigate to Devices & Networks and select the Open Controller.
3. Open Properties > PROFINET interface [X1] > IPv4 addresses.
4. Check "Use router" and enter the IP address of a router that the PLC can reach. Acceptable values:
   • The Windows side IP of the Open Controller itself (e.g., 10.108.x.1) if Windows IP forwarding is enabled — see Path B.
   • A plant router on the PLC subnet that also has a path to the Windows subnet.
5. Navigate to Properties > DNS server and enter the plant DNS server IP (e.g., 10.108.x.10).
6. Compile and download the hardware configuration to the SoftwarePLC.
7. Cycle power on the Open Controller so the new routing table is loaded by RTX.

Verification

• From the TIA Portal Online & Diagnostics view, open PROFINET diagnostics > DNS. The configured DNS server should show as reachable.
• In the LHTTP test program, monitor LHTTP_Client.status. A hostname call should now return status = 16#0000 with response_code = 200.

6. Solution Path B — Enable Routing on the Windows Side

If no physical router exists between the two subnets, the Open Controller's Windows installation can act as the router. The Windows NIC on the 10.108.x.x subnet and the SIMATIC RT-VMM virtual NIC (typically 192.168.1.1) sit on different subnets. Enable IP forwarding so the PLC's resolver can reach the Windows DNS server.

PowerShell steps (run elevated)

# Enable IP forwarding on Windows
Set-NetIPInterface -Forwarding Enabled

# Confirm
Get-NetIPInterface | Select-Object InterfaceAlias, Forwarding

# Optional: add a static route from PLC subnet to Windows subnet
route ADD 192.168.1.0 MASK 255.255.255.0 10.108.x.1 METRIC 1 IF <interface_index>

Replace 10.108.x.1 with the Windows side IP of the Open Controller. Once forwarding is enabled, configure the TIA Portal router as in Path A pointing to the Windows NIC IP.

7. Solution Path C — Local DNS Relay on the Windows Side

For plants where the IT department cannot add static routes or enable forwarding, deploy a lightweight DNS proxy on the Windows side of the Open Controller. The proxy listens on the SIMATIC RT-VMM adapter (192.168.1.1:53) and forwards queries to the corporate resolvers.

Recommended tools (free / open source)

• dnsmasq — small DNS forwarder, runs as a Windows service via Windows DNS service alternatives.
• Acrylic DNS Proxy — Windows-native, GUI configuration.
• Technitium DNS Server — supports forwarders and caching.

Example dnsmasq configuration

# /usr/local/etc/dnsmasq.conf
# Listen only on the SIMATIC RT-VMM adapter
listen-address=192.168.1.1
bind-interfaces

# Forward all queries to the corporate DNS
server=10.108.x.10
server=10.108.x.11

# Cache results
cache-size=1000

Then configure the TIA Portal DNS server field as 192.168.1.1 (the Windows side of the SIMATIC RT-VMM adapter). Because this address is on the same subnet as the PLC, no router is required in TIA Portal — the DNS server is considered local by the resolver.

Verification

# From the Open Controller Windows side
nslookup api.example.com 192.168.1.1
# Should return the corporate DNS response

8. Solution Path D — Host File Override (Engineering / Test Only)

For lab testing, populate the Windows side C:\Windows\System32\drivers\etc\hosts file with the resolved IPs of the cloud endpoints. Because the LHTTP socket is bound through hwID := "Local~PC_communications_interface", the Windows resolver performs the lookup. This is the same path that makes IP-address-based calls succeed.

# Example hosts entry
203.0.113.45  api.example.com
203.0.113.46  telemetry.example.com

9. Parameter Table — TCON / LHTTP Configuration

10. LHTTP Status / Error Code Matrix

11. Verification Checklist

1. Open a Windows command prompt on the Open Controller and run nslookup api.example.com 10.108.x.10. Confirm the IP address is returned.
2. Run the same test against the configured TIA Portal DNS server IP. Confirm reachability.
3. From the PLC program, call LHTTP with an IP-based URL — confirm response_code = 200.
4. Call LHTTP with the hostname URL — confirm same response.
5. Inspect the LHTTP response_header buffer for the Host: field. It must contain the original hostname, confirming TLS SNI was negotiated.
6. Monitor LHTTP_Client.diagnostics.info output DB for connection establishment time and DNS resolution duration.

12. Edge Cases and Field Notes

• IPv6 DNS servers: The SoftwarePLC resolver in RTX currently supports IPv4 DNS only. IPv6 resolvers are ignored even when configured.
• DNS over HTTPS (DoH): Not supported by the SoftwarePLC resolver. Use plain DNS (UDP/TCP 53).
• Multiple DNS servers: The PLC tries each in order. If the first server is unreachable, the second is queried after a 3-second timeout.
• TLS SNI mismatch: If you replace the hostname with an IP in the URL, modern TLS endpoints will reject the handshake. Always keep the original hostname in url.
• Plant VPN / Proxy: If the corporate network requires a web proxy, LHTTP does not support HTTP CONNECT or HTTPS proxying natively. Use the Windows system proxy settings and ensure Local~PC_communications_interface inherits them.
• Windows firewall: The first time LHTTP opens an outbound socket, Windows Defender Firewall prompts for permission. Allow access on the Windows side.

13. Diagnostic Procedure (5-Step)

1. Confirm symptom: Toggle between hostname and IP URL in LHTTP. If only the IP works, DNS is the issue.
2. Check PLC routing table: In TIA Portal Online & Diagnostics > Routing table, look for a default route.
3. Check DNS field: Under Device properties > DNS, verify the address is correct and matches the subnet policy (local vs off-subnet).
4. Ping from Windows side: ping 10.108.x.10 from the Open Controller's Windows shell — must succeed.
5. Test resolver: From the PLC, set DNS to 192.168.1.1 and use Path C. If successful, the original DNS server was simply unreachable.

14. Alternate Platform Notes

For engineers migrating this pattern to other Siemens platforms:

• S7-1500 (non-OC): No Windows side; DNS must be configured as a direct field. The PLC must have a route to the DNS server or the DNS server must sit on the PLC's subnet.
• S7-1200: LHTTP not supported; use the Web Client instructions in TIA Portal. DNS behaves identically.
• LOGO! 8.4: Cloud connectivity via the LOGO! CMR; DNS is handled by the CMR router. Direct DNS configuration is not exposed.
• Third-party IPC (e.g., Beckhoff CX): No dual-stack separation; the PLC runtime owns the physical NIC directly. DNS resolution is straightforward.