Resolving SEP Firewall Blocking Siemens TIA Portal Discovery

Problem Overview

When Symantec Endpoint Protection (SEP) is installed on an engineering workstation running Siemens SIMATIC Manager, Primary Setup Tool (PST), or TIA Portal, the "Accessible Nodes" / "Find Nodes" function fails to return any S7-CPU, S7-1200, S7-1500, ET 200, SCALANCE switch, or HMI Panel. The same engineering station can usually reach the same devices via "ping" or via direct IP entry, but the broadcast-based discovery mechanism returns an empty list. Disabling the SEP firewall restores discovery immediately, confirming that the endpoint security client is the root cause.

This behavior has been confirmed against SEP 12.1.6 (12.1 RU6 MP6), build 7061 and the broader SEP 12.x family. The blocking component is the Network Threat Protection / Network Protect subsystem, which intercepts the PROFINET Discovery and Configuration Protocol (PN-DCP) broadcast frames used by every Siemens tool to enumerate accessible nodes.

The engineering consequence is significant: commissioning engineers cannot perform "Online > Accessible Nodes", Starter cannot enumerate SINAMICS drives, and WinCC cannot resolve HMI targets. Because corporate policy forbids fully disabling the endpoint firewall, the correct remediation is to add targeted application exceptions, port exceptions, and MAC/protocol exceptions inside SEP, then verify the discovery path.

Root Cause Analysis

Siemens engineering tools use a multi-layer discovery stack that is fundamentally incompatible with strict host-based firewalls configured in their default state.

How Siemens Discovery Works

When the user clicks Online > Accessible Nodes in TIA Portal, the engineering station transmits an Ethernet frame to the reserved PROFINET multicast MAC address 01:0E:CF:00:00:00. This frame is a Layer-2 DCP IdentifyRequest multicast carried inside a UDP datagram on destination port 34964. Each PROFINET device on the broadcast domain is required by the PROFINET specification to reply with a DCP IdentifyResponse that contains the device's IP, name, MAC, vendor ID, and device ID. TIA Portal correlates these replies and populates the device tree.

What SEP Blocks

SEP's Network Threat Protection engine inspects outbound and inbound frames against three policy classes:

1. Firewall rules — port/protocol/address matchers that operate at Layer-3/4.
2. Application Control / System Lockdown — per-executable and per-DLL allow/deny lists, configurable per Broadcom's Device Control and Application Control documentation.
3. Network Protect — Layer-2 broadcast and multicast filter that drops frames sent to non-internet multicast groups, including the PROFINET DCP multicast 01:0E:CF:00:00:00.

Disabling only the firewall rule is not enough: Network Protect is a separate driver-level component (typically the SymIron / Teefer miniport) that sits below the Windows Filtering Platform and blocks the frame before any WFP-aware tool sees it. This is why "disable Windows Firewall" alone does not reproduce the problem, and why "disable SEP firewall" alone does fix it — the SEP firewall driver is the same component hosting Network Protect.

Affected Siemens Software and Components

Protocol and Port Reference

Add the following ports and protocols to the SEP firewall exception set. These are the values Siemens engineering stations require; they are not policy recommendations but the technical minimum for PROFINET conformance class A/B/C and S7 communication.

Step-by-Step: Configure SEP Exceptions for Siemens Discovery

The procedure below is written for SEP 12.1 RU6 MP6 (build 7061) and later SEP 14.x / 16.x clients managed by SEPM (Symantec Endpoint Protection Manager). Local policy editing on the engineering station is identical when SEPM is not used.

Prerequisites

• Local administrator rights on the engineering station, or a delegated SEPM policy with Password Protect Symantec Endpoint Protection disabled for the duration of the change.
• Read access to the SEP client logs at C:\ProgramData\Symantec\Symantec Endpoint Protection\<version>\Data\Logs — specifically FWLog, IDSLog, and NetProtect.log.
• Wireshark or Microsoft Network Monitor installed for verification (optional but recommended).
• A known-good target PLC on the same subnet (e.g. S7-1500 with PROFINET interface enabled).

Step 1 — Identify the Blocking Component

1. Open the SEP client UI and select Change Settings > Network Protect.
2. Confirm that Network Protect is enabled and Network Threat Protection is enabled.
3. Run a discovery in TIA Portal. If the device list is empty, proceed.
4. From an elevated command prompt, run netstat -anob | findstr 34964 — this confirms whether any Siemens process has the DCP socket open. If nothing is listed, the SEP driver has already dropped the request before socket bind.
5. Temporarily disable only Network Threat Protection (do not disable the firewall engine) and repeat the discovery. If the list populates, Network Protect is the culprit and the configuration in Steps 2–4 below is required. If the list is still empty, proceed to Step 5 for application-level exceptions.

Step 2 — Add the PROFINET DCP Multicast MAC to Network Protect Allow-List

1. In SEPM, navigate to Clients > Policies > Network Threat Protection, and edit the policy assigned to the Siemens engineering workstation group.
2. Select Exceptions > Edit list > Add > MAC Address.
3. Enter destination MAC 01-0E-CF-00-00-00 and mark the entry as Allow.
4. Add the IPv4 multicast equivalent 224.0.0.1 and the PROFINET-specific link-local scope address range as a separate host exception. PROFINET IO controllers do not normally use IP multicast for DCP, but a subset of devices (S7-1500 with RADIUS, SCALANCE X-200/XB-200) reply on 239.255.255.255 for diagnostic discovery.
5. Push the policy to the engineering group and wait for the SEP heartbeat cycle (default 60 s).

Step 3 — Add the Required UDP/TCP Ports to the Firewall Policy

1. In SEPM, open Policies > Firewall for the same group.
2. Add the following Allow rules (block-by-default is the SEP default, so each is required):

3. Scope each rule to the engineering station IP, or to the PLC subnet, to avoid opening these ports to the corporate network.
4. Save and push the policy.

Step 4 — Add the PROFINET Ethertypes as Frame Exceptions

For IRT-class PROFINET networks, real-time frames are tagged with Ethertype 0x8892 (PROFINET RT) and 0x88CC (LLDP). These are not matched by port-based firewall rules.

1. Under Network Threat Protection > Exceptions > Add > Ethernet Protocol, add:
   • Ethernet Type: 0x8892, Action: Allow
   • Ethernet Type: 0x88CC, Action: Allow
2. Apply the policy. IRT diagnostics in TIA Portal (Topology > Compare offline/online) will now succeed.

Step 5 — Add Application Exceptions for the Siemens Toolchain

Even with port rules, the SEP Application Control engine can block DLLs that the Siemens process loads. Per the Broadcom SEP Application Control documentation, allow the following executables and DLLs on the engineering station:

Step 6 — Verify Network Protect is the Culprit vs. the Firewall

Use the SEP client's built-in Connection Tracking (live firewall log) under View Logs > Traffic:

1. Set the log filter to Action: Blocked and Protocol: UDP.
2. Trigger a TIA Portal accessible-nodes scan.
3. Look for 0.0.0.0:<ephemeral> -> 224.0.0.1:34964 entries with a Network Threat Protection drop reason. This is the smoking gun.
4. If the drop reason is Firewall instead of Network Threat Protection, Step 3 rules are missing; if the reason is Network Protect, the MAC exception in Step 2 is missing.

SEP Build-Specific Notes

Network Topology & Discovery Flow

Verification

1. Re-open TIA Portal and click Online > Accessible Nodes. The list should populate within 5–10 seconds with every PROFINET device on the local subnet.
2. In SIMATIC Manager, select PLC > Display Accessible Nodes (F5). S7-300/400/1200/1500 CPUs should appear in the result tree.
3. Launch Starter and verify that SINAMICS drives on the same subnet are discovered.
4. Run Wireshark with a capture filter of udp port 34964 while triggering a scan. Confirm that an IdentifyRequest is sent and at least one IdentifyResponse is returned within 3 seconds.
5. From an elevated prompt, run netsh advfirewall show allprofiles and confirm Windows Firewall is unchanged. The fix must work with SEP enabled — not by disabling it.
6. Reboot the engineering station and re-verify. SEP services (SymIron, SMC) load at boot; if the exceptions are not in the persisted policy, they will be lost.
7. Re-run a TIA Portal download to a CPU to confirm TCP/102 S7 communication is unaffected by the new rules.

Troubleshooting Matrix

Alternative Mitigations (When IT Cannot Modify Policy)

1. Use a non-SEP subnet — Configure a dedicated engineering VLAN where the SEP client is excluded by GPO. Common in plant environments where the engineering PC uses two NICs: one corporate (SEP-protected) and one plant network (SEP excluded).
2. Loopback to a local S7-PLCSIM — For offline program development only, PLCSIM bypasses DCP entirely and uses a virtual adapter not subject to Network Protect.
3. Direct IP entry — In TIA Portal, manually type the CPU IP into the device address field. The TCP/102 connection still requires the firewall exception, but DCP is not required for that path.
4. PRONETA with offline topology — PRONETA can load a saved network scan from a USB stick taken from a non-SEP machine; not a real-time fix but useful for audits.
5. Convert to S7 routing — Configure an S7-1500 as a router in TIA Portal topology and access downstream devices via the CPU's IP rather than broadcast discovery.

Long-Term Hardening

• Create a dedicated Siemens Engineering computer group in Active Directory and assign the policy exceptions above only to that group, not to the global engineering OU.
• Document the policy in a corporate exception register; auditors will ask for justification, and the PROFINET standard (PROFINET specification, IEC 61784-2) is the technical authority.
• Lock the Siemens tool installation path with Application Control System Lockdown to prevent unrelated software from impersonating Siemens tools to gain the open ports.
• Log SEP exceptions to SIEM (Splunk, Sentinel) so that any rogue executable piggybacking on the open UDP 34964 port is visible to the SOC.
• Re-evaluate the policy when migrating to a new SEP major version (e.g. SEP 16 to SEP 17); Broadcom's release notes usually call out changes to Network Protect default behavior.