Resolving S7-319F OpenVPN Detection in TIA Portal V13 via TAP Bridged Mode

Problem Statement

Engineers commissioning a SIMATIC S7-319F safety PLC for remote service over a 3G cellular link (Teltonika RUT500) frequently find that the PLC's integrated web server responds correctly when accessed through an OpenVPN tunnel, ISO-TSAP (TCP port 102) connectivity is confirmed with a port scanner, and basic ping tests succeed. Despite this, TIA Portal V13's "Accessible devices" function never lists the S7-319F CPU, and a download to the target device fails because the engineering station cannot resolve the S7 CPU's PROFINET discovery handshake.

This article documents the root cause, the working solution (switching the OpenVPN tunnel from tun routed mode to tap bridged mode and disabling DHCP on the bridge), and the complete commissioning procedure for TIA Portal V13, the Teltonika RUT500, and the S7-319F-3 PN/DP safety controller.

Affected Components and Versions

Technical Background: DCP, ISO-TSAP, and the PROFINET Discovery Handshake

TIA Portal's "Accessible devices" workflow performs device identification using two distinct protocol families. Understanding the difference is the key to solving the remote access problem.

PROFINET DCP (Discovery and Configuration Protocol)

PROFINET DCP is defined in IEC 61784-2 and operates directly on top of Layer 2 Ethernet. DCP uses the Ethernet multicast destination address 01:0E:CF:00:00:00 and the EtherType 0x8892 (PROFINET). DCP frames are never routed; they are confined to the broadcast domain of the Ethernet segment on which they originate. DCP performs four functions:

• Identify – a multicast request asking "who is out there?"
• Hello – an unsolicited multicast announcement from a device on link-up
• Get / Set – read or write the station name, IP parameters, and reset behavior

The S7-319F-3 PN/DP responds to DCP Identify requests with its MAC address, station name (e.g. plc-cpu-1), current IP, and device role. TIA Portal uses this response to populate the "Accessible devices" tree.

ISO-TSAP / S7Comm (TCP port 102)

Once a candidate device is known (either from DCP, from the project, or from a manually entered IP), TIA Portal opens a TCP connection to port 102 (ISO Transport Service Access Point) and exchanges S7Comm PDUs. S7Comm is a pure Layer 4/7 protocol that can traverse any IP network, including a routed OpenVPN tunnel. The fact that nc -vz <plc-ip> 102 returns success is proof that S7Comm itself is functional.

Root Cause: OpenVPN TUN Mode Is a Layer 3 Construct

OpenVPN can be configured with two virtual interface types:

• dev tun – creates a Layer 3 point-to-point interface. The TUN device carries IP packets only; Ethernet headers are stripped at the ingress of the tunnel. Routing (not bridging) is used to reach the remote subnet.
• dev tap – creates a Layer 2 virtual Ethernet interface. The TAP device carries full Ethernet frames, including MAC addresses and the EtherType field. TAP interfaces are added to a software bridge together with the physical Ethernet adapter, making the remote site appear as if it were on the same broadcast domain as the local network.

When the RUT500 (or any other OpenVPN peer) is configured as a TUN client, DCP multicast frames generated by TIA Portal never leave the engineering station's physical LAN. They are not IP packets and therefore cannot be encapsulated in a TUN tunnel. Even if they could be encapsulated, the destination MAC 01:0E:CF:00:00:00 would still be confined to the tunnel's virtual interface, and the S7-319F's DCP response frames would never find their way back to the engineering station.

This is also the reason why vendor-supplied industrial VPN appliances (for example the eWON Flexy / Cosy) are marketed as the only solution that supports "Accessible devices"; they typically run an OpenVPN TAP bridge plus PROFINET-aware filtering.

Prerequisites

1. SIMATIC S7-319F-3 PN/DP CPU with a known static IP address (for example 192.168.0.10/24), gateway 192.168.0.1.
2. Teltonika RUT500 with a public SIM card and a stable 3G/HSPA+ link. Firmware RUT5XX.0.0.R (or later) is recommended; the OpenVPN feature is included in all stock firmware images.
3. An OpenVPN server reachable from the RUT500 (can be the engineering station, a cloud VPS, or a corporate firewall). The Teltonika RUT500 itself can act as an OpenVPN server; in that case the engineering station runs the OpenVPN client.
4. OpenVPN Connect installed on the engineering station. The official client is available from:
   • OpenVPN Connect on the Apple App Store
   • OpenVPN Connect on Microsoft Store
   • OpenVPN Connect on Google Play
5. TIA Portal V13 with the latest service pack installed (V13 SP1 or V13.2 is recommended for Windows 10 compatibility).
6. Static project file (.ap13) in which the S7-319F CPU already has a configured IP address. The project file is required because "Accessible devices" cannot be used over the VPN; TIA Portal must know the IP from the project.
7. OpenVPN certificates and keys (CA cert, server cert/key, client cert/key, optional TLS-auth key) generated with Easy-RSA or the Teltonika built-in PKI.

Solution Architecture

The fix is to switch the OpenVPN topology from a routed (TUN) tunnel to a bridged (TAP) tunnel. In TAP mode, the RUT500 acts as a transparent Layer 2 bridge: every Ethernet frame – including PROFINET DCP – sent by the engineering station is forwarded to the S7-319F as if both devices were physically connected to the same switch. DHCP must be disabled on the bridge because the engineering station should not hand out IP addresses to the remote site, and the S7-319F already has a static IP.

Step-by-Step Configuration

Step 1 – Prepare the OpenVPN Server Configuration

On the OpenVPN server (a cloud VPS, a corporate firewall, or a second RUT500), define a TAP-based server. Replace 192.168.0.0 255.255.255.0 with the actual LAN subnet of the remote site.

# /etc/openvpn/server.conf (Linux server example)
port 1194
proto udp
dev tap0
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-auth ta.key 0
keepalive 10 60
persist-key
persist-tun
status openvpn-status.log
verb 4
# Bridge tap0 with the physical LAN interface (eth0)
# Performed in /etc/network/interfaces or by an up-script:
#   brctl addif br0 tap0 eth0
#   ip link set br0 up

Step 2 – Configure the Teltonika RUT500 as OpenVPN Client (TAP)

1. Log into the RUT500 web UI at http://192.168.1.1 (default credentials: admin / admin01).
2. Navigate to Services → VPN → OpenVPN.
3. Add a new OpenVPN client instance and assign it a name, e.g. tap-tia.
4. Enable the client and paste the server-side configuration block. Critical parameters:

client
dev tap
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA256
cipher AES-256-CBC
verb 4

5. Upload the CA certificate, the client certificate, the client key, and (if used) the TLS-auth static key via the file manager.
6. In Network → Interfaces, locate the new tap_tia interface created by the OpenVPN client and add it to the LAN bridge (br-lan). The RUT500 uses OpenWrt under the hood; the resulting configuration should resemble:

config interface 'lan'
    option type 'bridge'
    option ifname 'eth0 tap_tia'
    option proto 'static'
    option ipaddr '192.168.0.1'
    option netmask '255.255.255.0'
    # DHCP server disabled on this bridge
    option dhcp '0'

7. Disable the built-in DHCP server on the LAN bridge: Network → Interfaces → LAN → DHCP Server → uncheck Enable. This step is mandatory; otherwise the RUT500 will hand out addresses to the engineering station and conflict with the site network.
8. Apply changes and verify that the OpenVPN client reports CONNECTED,SUCCESS in the log.

Step 3 – Configure OpenVPN Connect on the Engineering Station

1. Install OpenVPN Connect for Windows (or the macOS / iOS / Android variant referenced above).
2. Import the .ovpn profile provided by the OpenVPN server administrator. The profile must contain dev tap in the configuration block; OpenVPN Connect respects this directive.
3. Connect. A new network adapter, TAP-Windows Adapter V9 (or tun0/tap0 on macOS/Linux), appears in the network list.
4. Assign the engineering station a static IP in the same subnet as the PLC, for example 192.168.0.100/24, gateway 192.168.0.1. Disable any conflicting DHCP lease on the TAP adapter.
5. From an elevated command prompt, verify that the engineering station can ping 192.168.0.10 and that arp -a shows the S7-319F's MAC address. Seeing the MAC in the ARP cache is positive proof that the bridge is working at Layer 2.

Step 4 – TIA Portal V13 Configuration

1. Open the TIA Portal project that contains the S7-319F CPU.
2. In the project tree, right-click the CPU and select Properties → PROFINET interface [X1] → Ethernet addresses. Confirm that the static IP 192.168.0.10 and the correct subnet mask are configured.
3. If "Accessible devices" is still required, open it from Online → Accessible devices. The S7-319F should now appear with its station name and PROFINET device icon.
4. For an online connection, select the CPU, click Go online, and choose PN/IE as the interface. In the next dialog, type the IP address 192.168.0.10 directly and check Show all compatible devices.
5. Enter the password of the CPU's protection level (if configured) and click Go online.
6. Verify that the online view shows the actual operator panel status, error LEDs, and online block consistency.

Verification Checklist

1. Layer 1/2 verification: arp -a on the engineering station lists the S7-319F MAC (format 00-0E-8C-xx-xx-xx for Siemens PROFINET devices).
2. Layer 3 verification: ping 192.168.0.10 returns <500 ms over 3G with no packet loss.
3. Layer 4 verification: Test-NetConnection 192.168.0.10 -Port 102 (PowerShell) returns TcpTestSucceeded: True.
4. PROFINET DCP verification: Run a third-party PROFINET scanner (e.g. PROFINET Discovery Tool from Siemens) against the TAP interface. The CPU should respond with its station name and order number.
5. TIA Portal verification: Online → Accessible devices lists the S7-319F. Clicking Flash LED should make the CPU's LINK/ACTIVITY LED blink at 2 Hz.
6. Online function verification: Go online succeeds. Online block consistency is reported as consistent for all standard and safety blocks.

Troubleshooting Matrix

Advanced Configuration: MTU, MSS, and PROFINET Real-Time

OpenVPN adds approximately 50–80 bytes of encapsulation overhead (UDP header, OpenVPN opcode, TLS record, HMAC). Over a 3G link with limited MTU, the default 1500-byte Ethernet frame is too large. Symptoms of MTU problems include: tunnel connects, pings work for small payloads, but TCP 102 hangs and large HTTP downloads time out.

Apply the following parameters to both the server and the client configuration:

tun-mtu 1400
mssfix 1300
fragment 1300

For PROFINET real-time (RT) traffic on a TAP bridge, additional care is required. PROFINET RT frames are scheduled by the controller with a typical cycle of 1 ms. Over a 3G link with 100–300 ms latency, real-time is impossible; only the non-real-time channels (NRT) and PROFINET DCP function. This is acceptable for engineering access but not for controlling I/O. Use the VPN strictly for commissioning, diagnostics, and program download – never for closed-loop control.

Security Considerations

• Use TLS-auth: Add tls-auth ta.key 1 to the client and tls-auth ta.key 0 to the server. This prevents DoS attacks and unauthorized TLS handshakes.
• Use AES-256-GCM where supported: Newer OpenVPN builds (2.4.x and later) negotiate AES-256-GCM via the ncp-ciphers directive.
• Restrict the TAP bridge: The RUT500's firewall must drop any traffic not destined to 192.168.0.10:102 or the PLC's web server ports. The S7-319F should never be exposed to the open internet.
• Disable unused services: On the S7-319F, disable Web server, FTP server, and SMTP client unless they are required for diagnostics. Use TIA Portal's Protection & Security settings to enforce a strong CPU password.
• Disable PROFINET IO on the remote interface if the plant network has a separate PROFINET controller; otherwise DCP frames from the engineering station could disturb the real-time network.

Alternative Solutions

Operational Notes and Field-Proven Caveats

• The RUT500's OpenVPN implementation in firmware versions older than RUT5XX.0.0.R occasionally drops the TAP interface on cellular handover. Upgrade to the latest stable firmware (RUT5XX.0.0.R or later) before relying on a permanent remote engineering link.
• Disable the RUT500's WiFi interface if the engineering station must not be allowed to reach the PLC through WiFi while the VPN is down. The TAP bridge and the WiFi AP are part of the same br-lan by default.
• When commissioning the safety program from remote, remember that a download to the F-CPU requires a stop → download → restart of the safety program. Coordinate with the responsible safety engineer before triggering an F-stop.
• On Windows 10 and Windows 11, the TAP-Windows Adapter V9 driver is included with the OpenVPN Connect installer. If the driver fails to install, run the bundled .../driver/tapinstall.exe as administrator.

Frequently Asked Questions