Siemens S7 CPU Port Configuration in NetPro for PROFINET

1. Overview: Port Architecture in SIMATIC S7 Communication

A SIMATIC S7 CPU equipped with a PROFINET interface (PN) does not expose a single, monolithic communication endpoint. Each CPU presents one or more physical Ethernet ports (Port 1, Port 2, and where applicable Port 3 on CPUs such as the S7-1500 with multiple PN interfaces) over which the operating system runs a transport-layer stack that demultiplexes many concurrent logical sessions. Configuring communication therefore requires engineers to distinguish three distinct concepts that are often conflated in field practice:

• Physical port — the RJ45 socket on the front of the CPU (or on a CM/CP plug-in module). Each socket has its own MAC address and link status independent of the others.
• Interface — the PROFINET interface (X1, X2) to which the physical port is bound. The interface owns the IP address and the PROFINET device name.
• Logical port / connection endpoint — the application-layer identifier (TCP port, UDP port, TSAP, connection ID) used by a specific protocol session (S7 communication, Modbus TCP, PROFINET I-Device, HTTP, etc.).

The logical port number does not define the protocol that runs on it. The opposite is true: each protocol specification recommends a default port (e.g. port 502 for Modbus TCP, port 80 for HTTP, port 161/162 for SNMP), and the engineering tool or stack then binds the session to that port. Operators are free to remap these ports, but doing so is a recommendation, not a rule, and no controller-level mechanism forces the recommended allocation to be respected.

2. Physical Ports vs Logical Ports on a PROFINET CPU

An S7-300 CPU with PN interface (for example CPU 315-2 PN/DP, 6ES7315-2EH14-0AB0) provides two physical Ethernet sockets labelled Port 1 and Port 2. These belong to a single PROFINET interface (X1) with one IP address. Both sockets are wired through an internal 2-port switch and are therefore equivalent from an IP perspective — the only operational differences are:

On an S7-1500 CPU (for example CPU 1515-2 PN, 6ES7515-2AM02-0AB0) the first PN interface has two ports and the second PN interface has one additional port. Each port maintains independent link state and LLDP topology information, but all ports within one PN interface share the same IP subnet, the same PROFINET device name, and the same set of logical application endpoints.

Multiplexing is the property that allows a single physical port (or any of the ports within an interface) to carry many simultaneous logical sessions. Each session is identified by the 5-tuple {protocol, source IP, source port, destination IP, destination port}. From the controller's perspective, an incoming TCP connection to port 502 is dispatched to the Modbus TCP server task, while an incoming connection to TSAP 01.01 on port 102 is dispatched to the S7 communication task. The same physical RJ45 socket therefore services both.

3. Standard TCP/UDP Port Assignments for SIMATIC Services

The following table summarises the registered and de-facto port assignments used by SIMATIC CPUs with PROFINET. These are the values you should expect to see in the protocol analyser when no user-defined remapping has been performed.

General background on port multiplexing and the client-server port model is documented at the Port (computer networking) reference. The principle that the protocol defines the port, not the port defining the protocol applies equally to industrial stacks and IT stacks.

4. Modbus TCP Port 502 and S7 CPU Server Configuration

Modbus TCP always uses TCP port 502 as the server listen port. The S7 CPU acts as the Modbus server; any Modbus client (HMI, SCADA, third-party controller) opens a TCP connection to <CPU_IP>:502 and the request is interpreted by the Modbus TCP FB block on the controller.

To enable Modbus TCP on an S7-300 PN CPU using the ModbusTCP PN-CPU library (FB “MB_REDSV” / “MB_REDCL” or the example project), configure the following in the CPU properties or in the FB instance:

1. Assign the CPU a fixed IP address (do not rely on DHCP for Modbus servers).
2. Open the firewall rules on any intermediate router to permit TCP 502 inbound to the CPU.
3. Download the ModbusTCP blocks from the Siemens example support page (entry ID 22660304 historically, current link on the Siemens support portal).
4. Place MB_REDSV (server) in OB1 and set ID parameter to a free connection ID (for example 1).
5. Set the LOCAL_PORT parameter to W#16#01F6 (= 502 decimal). This is the only value that complies with the Modbus specification for server listen port.

The number of simultaneous Modbus clients is limited by the S7 connection resources of the CPU. Typical values:

5. PROFINET I-Device Port Configuration in NetPro

An I-Device (Intelligent IO Device) is an S7 CPU that acts as a PROFINET IO device on an upper-level IO controller while simultaneously running its own user program and exposing its own IO to a lower-level IO controller or another controller. The configuration is split between HW Config (where the I-Device is assigned its slots) and NetPro (where the logical connections are defined).

In NetPro (STEP 7 V5.x) the port-related fields for an I-Device are:

The Local Address / Port field of the I-Device connection is not the TCP port number visible on the wire (which is always 102 for S7 communication). It is the TSAP (Transport Service Access Point), a two-byte identifier that the S7 communication layer prepends to the connection request. The TSAP format is:

TSAP = [rack/slot byte] [submodule byte]
= 0x10 0x01 for rack 0, slot 1 (CPU)
= 0x01 0x01 alternative TSAP for subslot addressing

When you configure an I-Device, the engineering tool automatically suggests the local TSAP. You should leave the default unless the same CPU already uses that TSAP for another connection. The first byte of the TSAP encodes rack/slot; the second byte encodes the connection resource. For an S7-1500 I-Device in TIA Portal, the equivalent fields appear in Devices & Networks > Connections > Properties > Address Details.

6. Connection IDs, TSAPs, and the Difference to TCP/UDP Ports

This is the most common point of confusion in field practice. Three identifiers coexist on every S7 communication relationship:

The Local Connection ID is the handle that the user program uses to address the connection (e.g. as the ID input of PUT, GET, BSEND). It is project-scoped — it does not appear on the wire at all. The TSAP appears in the TPDU header of the ISO-on-TCP connection on TCP port 102. The TCP port is the actual port 102 socket the operating system listens on.

7. Multiplexing Multiple Protocols on a Single PN Interface

Because the S7 CPU's PN interface runs an integrated TCP/IP stack, the same physical port (or any of the two switched ports) can simultaneously service:

• PROFINET RT cyclic data (Layer 2, Ethernet type 0x8892)
• PROFINET Context Manager / DCP (UDP 34964)
• S7 communication (TCP 102 / RFC1006)
• Modbus TCP (TCP 502)
• PG online access (TCP 102, dynamically assigned local port)
• HMI / WinCC Runtime (TCP 102)
• Web server (TCP 80 / 443)
• SNMP (UDP 161)

Each session occupies a separate entry in the CPU's connection resource table. The internal scheduler demultiplexes incoming frames by matching the socket tuple, and dispatches the payload to the appropriate protocol task. There is no port conflict as long as the listen ports differ. The only practical caveat is CPU load: every active connection consumes a small amount of OB1 / OB82 / OB86 processing time and a connection resource block. On a fully loaded CPU 315-2 PN/DP, exceeding 8–10 active connections to non-PROFINET protocols can be felt in the PROFINET update time jitter.

8. Firewall, Router, and Network Security Considerations

Industrial firewalls and managed switches must permit the SIMATIC port set, or the controller will appear “offline” to the SCADA while remaining visible to PROFINET IO controllers on the same subnet. The minimum port set is:

When the S7 CPU is connected to an IT / OT boundary firewall, document the exact list and provide it to the network administrator. For environments using virtualised SCADA or virtualised engineering stations, the underlying hypervisor port list must also permit the same set — the VMware Ports and Protocols tool documents the additional management ports required (e.g. vSphere Client 902, ESXi management 443). Likewise, the engineering station's operating system port list must allow outbound traffic to TCP 102 / 502; the Windows service overview and network port requirements is the authoritative reference for the Windows side.

9. Step-by-Step: Configuring the Port Field in NetPro for an I-Device

The following procedure applies to STEP 7 V5.5 / V5.6 with a CPU 315-2 PN/DP or CPU 317-2 PN/DP configured as an I-Device.

1. Open the STEP 7 project and select the CPU acting as the I-Device.
2. Open HW Config and double-click the PN interface. Assign the CPU a fixed IP address and a PROFINET device name.
3. Place the I-Device interface in the slot table of the upper IO controller's PROFINET IO system.
4. Compile and save HW Config.
5. Open NetPro (menu Options > NetPro). The I-Device CPU appears in the station window.
6. Right-click the CPU > Insert New Connection.
7. Select the partner (the upper IO controller or the partner CPU). The connection type defaults to S7 connection.
8. Set Active connection establishment to No (passive) for the I-Device side. The partner CPU will be configured as active in its own project.
9. Open the Address Details dialog. The Local Port field shows the automatically generated TSAP (typically 10.01 for rack 0 slot 1). If this TSAP is already in use by another connection, increment the second byte (10.02, 10.03, ...).
10. Click OK, then Save and Compile (Ctrl+S). Download the NetPro configuration to the CPU.
11. Verify the connection is established using PLC > Monitor/Modify > Communication or via the diagnostic buffer (menu PLC > Diagnostics/Settings > Diagnostic Buffer).

10. Verification Checklist

After configuration, perform the following checks in order:

1. Wireshark capture on Port 1 — confirm that TCP traffic to port 102 (S7) or 502 (Modbus) reaches the CPU and is acknowledged.
2. Diagnostic buffer — look for entries "Connection established" (event ID 0x0B11 / 0x0B12) or "Connection aborted" (0x0B33). TSAP mismatches generate event "Connection request, partner TSAP not assigned".
3. Connection status in NetPro — select the connection and view the status icon (green = established, grey = not established).
4. Modbus client test — use a Modbus master tool (e.g. Modbus Poll, qModMaster) to read holding register 0 and confirm the CPU responds.
5. Firewall log review — confirm no TCP RST is being injected by an intermediate appliance that does not recognise the port/protocol pair.

11. Troubleshooting Matrix

12. Practical Notes and Field-Proven Caveats

• The Local Port field in NetPro is the TSAP, not the TCP port. The TCP port for S7 communication is always 102. Trying to “set the port to 502 for an S7 connection” is a misconfiguration and will fail to establish.
• Modbus TCP must always use TCP 502 on the server side. Clients may use any ephemeral port above 1024 as the source port.
• When the same CPU is used as both an I-Device and a Modbus server, total connection resources are shared. Plan for 2–3 I-Device connections plus the Modbus clients plus the HMI plus the engineering PG.
• Industrial firewalls that perform deep packet inspection may need an explicit rule to allow ISO-on-TCP (RFC 1006) frames on TCP 102. A plain “allow TCP 102” rule is not always sufficient because the payload starts with a length prefix and ISO session header, which some DPI engines interpret as non-S7 traffic.
• If the controller is behind a NAT, the source port of the client becomes meaningful. The NAT device must preserve the source port, otherwise the CPU's response will be dropped.
• S7-1500 CPUs allow configurable port numbers for the Web server, OPC UA server, and SNMP agent (TIA Portal > Properties > Web server / OPC UA). The Modbus TCP server port is fixed at 502.