Configuring S7-1500 Remote I/O Access Over VPN and Mobile

Overview: Remote I/O on a SIMATIC S7-1500 Across Routed Networks

Engineers frequently need to expose a SIMATIC S7-1500 CPU to remote I/O located on a separate LAN that is reachable only through a cellular (4G/5G) router and an IPsec / OpenVPN tunnel. The question is not whether it is possible — it is which protocol stack survives Layer-3 routing, and which one does not. PROFINET I/O is a real-time, Ethernet-Layer-2 protocol and therefore cannot be routed. S7 communication, on the other hand, sits on ISO-on-TCP (RFC 1006) or UDP, both of which are routable IP protocols. This article documents the protocols that work, the hardware that must be deployed at the remote site, the S7 connection-resource budgeting, the VPN topology, and a commissioning checklist that has been validated in field installations.

Why PROFINET I/O Cannot Cross a Router or VPN

PROFINET I/O uses Ethernet type 0x8892 (PROFINET RT) or 0x880A-PTCP for frame exchange, with no IP header. A standard IP router drops these frames because the destination MAC address is on a different Layer-2 segment and the frame is not IP. The same is true for PROFINET IRT (isochronous real-time) frames, which use a cut-through switching model that depends on line-rate Layer-2 forwarding. IPsec and OpenVPN tunnels are Layer-3 constructs and only carry IP packets, so the productive PROFINET I/O channel terminates at the edge of the tunnel.

The practical consequence is that the ET 200MP distributed I/O system documented in the SIMATIC S7-1500 / ET 200MP Manual Collection is a same-subnet architecture. Its interface modules (for example the IM 155-5 PN) are PROFINET devices and require an uninterrupted Layer-2 path back to the S7-1500 IO controller.

Two Valid Architectural Patterns for Remote I/O

Once the PROFINET constraint is accepted, two patterns cover almost every S7-1500 remote-I/O requirement over a mobile or VPN link:

Pattern A — IP-Connected Smart Remote Station

A small SIMATIC CPU (S7-1200 or an ET 200SP CPU) is installed at the remote site. The remote CPU owns its own PROFINET I/O locally (with update times that suit the field wiring). It then exchanges the consolidated process image with the S7-1500 master over an IP-routable protocol such as S7 PUT/GET, S7 client/server, or OPC UA. From the S7-1500's perspective, the "remote I/O" is now a routable peer on the VPN.

Pattern B — S7-1500 Master with Direct IP-Based Field Devices

The remote I/O is an IP-native device (for example a SITRANS field instrument, a SCALANCE switch's Web diagnostics, or a third-party Modbus TCP I/O block). The S7-1500 talks to it directly over TCP, UDP, or OPC UA. There is no PROFINET device relationship at all.

Both patterns are described in Siemens Application Example "Remote Communication via Mobile Network and VPN" (entry ID 24960449), which provides tested S7-1500 / S7-1200 project files and router configurations for SCALANCE M and third-party cellular routers.

Protocol Selection: S7 PUT/GET vs. UDP vs. OPC UA

S7 PUT/GET (S7 Communication)

PUT and GET are S7 instructions in the S7-1500 program editor that copy a data block (or a memory area) to or from a partner CPU. They ride on the S7 protocol, which is implemented as ISO-on-TCP (port 102) inside TIA Portal's "S7 connection" configuration. Because ISO-on-TCP is just TCP with a 4-byte TPDU prefix, it is fully routable across IP subnets and across an IPsec tunnel.

Configuration in TIA Portal:

1. Open Devices & Networks and add a new S7 connection between the S7-1500 and the remote CPU.
2. Set the partner IP address to the remote CPU's tunnel-side address (for example 10.10.20.5).
3. Set the local ID and connection resource. The S7-1500 reserves one PG/PC connection and one S7 connection resource per configured partner.
4. Enable Permit access with PUT/GET communication on the partner CPU's protection settings (TIA Portal > Device Configuration > Properties > Protection & Security).
5. Call PUT and GET instructions in the user program with the configured ID.

Maximum data per call is limited by the CPU type. The S7-1500 PUT/GET blocks accept a pointer of up to 462 bytes (old blocks) or 64 KB (newer variants), but the practical mobile-network sweet spot is 200–400 bytes per call to keep round-trip time acceptable.

Open User Communication over UDP — TUSEND / TURCV

When bandwidth is at a premium (cellular LTE-M, NB-IoT, or any capped APN), UDP is roughly 25–30 % lighter than TCP because there is no ACK stream, no three-way handshake, and no congestion-window bookkeeping. Siemens provides the TUSEND and TURCV instructions for S7-1500 / S7-1200 that use the standard Open User Communication over UDP.

Sample call structure for cyclic process data of 32 bytes from master to remote:

// SCL example — S7-1500 master, 100 ms tick
#iStatus := TUSEND(
    REQ        := "Clock_100ms",
    ID         := 1,
            // connection ID from TIA Portal net config
    LEN        := 32,
    DONE       => NULL,
    BUSY       => "udtSendBusy",
    ERROR      => "udtSendError",
    STATUS     => "wSendStatus",
    DATA       := "dbProcess".outData
);

UDP is connectionless. The application must implement its own sequence number, watchdog timer, and loss detection. For typical remote telemetry, a heartbeat counter incremented in the master and echoed by the remote is sufficient: if the echo does not advance within three cycles, mark the link unhealthy and fall back to a safe state.

OPC UA

If the S7-1500 firmware is V2.5 or higher, the CPU can act as an OPC UA server. The remote HMI or SCADA reads the process image over the standard OPC UA TCP binary protocol (port 4840). OPC UA is the cleanest choice when the remote endpoint is a Windows or Linux node that is not itself a Siemens CPU. It is also the only one of the three that gives you built-in encryption and authentication without a separate VPN, although a VPN is still recommended for cellular links.

VPN Topology and Network Addressing

VPN operates at OSI Layer 3. Once an IPsec or OpenVPN tunnel is established between two routers, the tunnel acts as a virtual routed path between the two LAN segments. The cellular router (for example a SCALANCE M876-4, a SCALANCE MUM856-1, or a third-party Robustel/Huawei/Siemens RUGGEDCOM RX15xx) is configured with:

• WAN side: APN settings, SIM credentials, and the IPsec / OpenVPN policy (pre-shared key, certificates, or IKEv2 with PSK).
• LAN side: A private subnet that does not overlap the central subnet. A common choice is 10.10.20.0/24 for the remote site and 10.10.10.0/24 for the central S7-1500 site.
• Routing: A static route (or the negotiated IPsec tunnel selectors) that maps the central subnet to the tunnel interface.

For PROFINET, this topology is broken: the remote ET 200MP cannot see the S7-1500 MAC address through the tunnel. For S7 / UDP / OPC UA, the topology is exactly right: both endpoints have an IP address on the virtual point-to-point link and TCP/UDP packets flow as if the two routers were a single switch.

Choosing the Remote CPU

The S7-1500 cannot be a PROFINET IO device, so it cannot sit at the remote end of a PROFINET line that is bridged across a VPN. The remote station must therefore be one of:

The S7-1500 / ET 200MP family is documented in the S7-1500 / ET 200MP Manual Collection, and the interface modules for the ET 200MP describe the IM 155-5 PN / IM 155-5 DP variants that connect ET 200MP I/O to a PROFINET or PROFIBUS controller.

S7 Connection-Resource Budgeting

Every S7 connection (HMI, PG, PUT/GET, Open User Communication) consumes a connection resource on the CPU. Exceeding the budget causes new connection attempts to be refused with diagnostic buffer entries such as "Connection resources exhausted". Budget by CPU:

Each TUSEND/TURCV pair uses two connection resources (one send + one receive). Each PUT or GET uses one connection resource. A common mistake is to instantiate a TURCV inside a multi-instance DB for every remote station; with eight remotes this is 16 resources and the S7-1200 runs out immediately. Use a single multiplexed pair with a polled station list instead.

Step-by-Step: S7-1500 Master → S7-1200 Remote over VPN

Prerequisites

• SIMATIC S7-1500 CPU with firmware V2.5 or later (V2.9 recommended for OPC UA).
• SIMATIC S7-1200 CPU (any DC/DC/DC variant) with firmware V4.4 or later.
• Two SCALANCE M / MUM routers (or compatible) with valid cellular subscription and IPsec VPN in routing mode.
• TIA Portal V17 or later with both CPU HSPs installed.
• Static public IP, dynamic DNS, or cellular APN that allows the central router to initiate the tunnel.

Procedure

1. Configure the cellular router at the remote site. Set LAN IP to 10.10.20.1/24, WAN to the cellular APN, and create an IPsec Phase-1 / Phase-2 policy that terminates on the central router. Forward UDP 500, UDP 4500 (NAT-T), and ESP (protocol 50) to the central endpoint. If the central endpoint is behind NAT, enable NAT-T and use a unique IKE ID.
2. Configure the central cellular router. Set LAN IP to 10.10.10.1/24, accept the IPsec tunnel from the remote router, and add a static route for 10.10.20.0/24 via the tunnel interface.
3. Verify the tunnel. From a central LAN PC, ping 10.10.20.1 (the remote router) and 10.10.20.5 (the S7-1200, after step 4). A 30–150 ms round-trip is typical for LTE; anything over 400 ms indicates a poor signal or roaming.
4. Assign static IP to the S7-1200. 10.10.20.5, mask 255.255.255.0, gateway 10.10.20.1. Disable the S7-1200 PROFINET IO controller role unless it is needed for local I/O.
5. Configure the S7-1500 interface. 10.10.10.10, mask 255.255.255.0, gateway 10.10.10.1. Add a router entry if the partner is on a different subnet (typical).
6. Build the S7 connection in TIA Portal. Insert > Connection > S7 connection. Partner address = 10.10.20.5. Local ID and connection ID auto-assigned. Mark "Establish active connection" if the S7-1500 should be the client.
7. Enable PUT/GET on the S7-1200. Properties > Protection > "Permit access with PUT/GET communication from remote partner." Set a CPU password to prevent unauthorized access.
8. Call PUT/GET in the S7-1500 program. Use a 100 ms cyclic OB (OB1 or OB35) and call GET first to read 32 bytes of remote input image, then PUT to write 16 bytes of remote output image.
9. Watch the diagnostic buffer. On the S7-1500, online > Diagnostics > Diagnostic buffer. Successful connection establishment is logged as event ID 0x0001 with text "Connection established." Repeated 0x01A4 ("Connection terminated") with STATUS = 0x8085 indicates a TLS or IPsec rekey — tune the IPsec lifetime to 8 h to match the S7 keep-alive.

Verification

• Force the S7-1200 outputs from the S7-1500 online watch table and confirm the remote I/O LED toggles.
• Disconnect the cellular antenna. The S7-1500 PUT/GET should report STATUS = 0x80A7 ("Connection terminated by remote") within 60 s. The application must treat this as a fault and hold outputs in their last safe state.
• Reconnect the antenna. Connection should re-establish within 10 s without a CPU restart.

Performance and Bandwidth Planning

A PROFINET I/O update of 1 ms cannot be achieved across a cellular link. Typical realistic numbers for VPN-tunneled cellular S7 communication:

For LTE-M and NB-IoT, stay below 10 kbps aggregate to avoid SIM data-plan surprises. For LTE Cat-4 and 5G, 100–500 kbps is sustainable for small I/O populations.

Troubleshooting Matrix

Security Considerations for Cellular Remote Access

• Disable online diagnosis from outside the tunnel. TIA Portal > Protection > "Remote access via WAN" must be unchecked on the S7-1500 unless the VPN is a trusted private link.
• Use a unique password per CPU. S7-1500 firmware V2.5 enforces strong passwords on the protection pane.
• Lock the S7-1200 protection level to "Complete protection with password" and require the password for PUT/GET access.
• Enable the S7-1500 security log (TIA Portal > Security > Log) and forward it to a central SIEM if the network supports it.
• Pin certificates. If using OPC UA, generate a server certificate with a 2048-bit RSA key, install the issuer on the SCADA client, and reject unknown issuers.

When the Requirement Truly Needs PROFINET Across Sites

If the application is genuinely tied to PROFINET I/O update times below 5 ms and the two sites must remain on different subnets, the only real options are:

1. Use a Layer-2 VPN such as EoIP (Ethernet over IP) on a MikroTik pair — non-Siemens, but technically functional. PROFINET will pass, but S7-1500 diagnostics, IRT, and MRP will not.
2. Install a private line or MPLS link between the two sites and treat them as one LAN — no routing at all.
3. Use a wireless bridge (5 GHz, 60 GHz, or private LTE) as a Layer-2 extension rather than IP routing.

None of these are "PROFINET over routed IP." They are Layer-2 extensions, and they break the moment the underlying WAN becomes a true IP-only link. For 95 % of remote I/O applications — SCADA telemetry, slow control, asset monitoring — Pattern A with an S7-1200 / ET 200SP CPU and S7/UDP/OPC UA is the right answer and is fully supported by the Siemens Application Example 24960449.