SCALANCE S615 VLAN Routing: Fixing Asymmetric Ping Between PLC and SCADA Subnets

The Siemens SCALANCE S615 (catalog number 6GK5615-0AA00-2AA2, with the related 6GK5615-0AA01-2AA2 variant for extended temperature) is a hardened industrial security appliance that combines a managed Layer 2 switch, a Layer 3 router, and a stateful inspection firewall in a single DIN-rail device. It is widely used on the plant floor to segment machine cells (typically 10.x.x.x or 172.16.x.x subnets) from the SCADA/DMZ layer (typically 192.168.x.x subnets), and to terminate VPN tunnels back to a central SINEMA RC server.

When you assign two IP interfaces to two VLANs and expect the S615 to route between them, the most common field failure is asymmetric reachability: pings succeed in one direction only, and TIA Portal on the SCADA side can browse and go online with PLCs on the other side, but the HMI cannot refresh tags in the opposite direction. This article reconstructs the failure pattern reported with VLAN 1 = 192.168.55.0/24 (SCADA) and VLAN 2 = 10.13.180.0/24 (PLC), with the S615 holding 192.168.55.1 on VLAN 1 and 10.13.180.140 on VLAN 2, and walks through the configuration changes that restore symmetric routing.

1. Problem Details

Reported configuration (from Web-Based Management, WBM):

• VLAN 1 (SCADA side): IP 192.168.55.1, subnet mask 255.255.255.0
• VLAN 2 (PLC side): IP 10.13.180.140, subnet mask 255.255.255.0
• Default gateway on VLAN 2 interface: 10.13.180.140 (the S615's own address)

Observed behavior:

• PC connected to VLAN 1 (192.168.55.x) can ping 10.13.180.140 (S615 on VLAN 2) and other VLAN 2 hosts. One-way success.
• Devices on VLAN 2 cannot ping 192.168.55.x hosts, including the S615's VLAN 1 interface.
• TIA Portal on VLAN 1 can browse and go online with VLAN 2 PLCs.

The TIA-can-go-online-from-VLAN-1 symptom is a strong indicator that the S615 is forwarding frames from VLAN 1 to VLAN 2; the failure is on the return path, in the firewall state table, or in the end-device default gateway. The "Default gateway 10.13.180.140" entry on the S615's own VLAN 2 interface is the most prominent smell-test failure: an interface cannot usefully route traffic to itself as the next hop.

2. Root Cause Analysis

On a SCALANCE S615, three independent configuration layers must agree for two-way IP traffic to flow between VLANs:

1. Layer 2 VLAN membership - which physical and logical ports belong to which VLAN, and whether frames are tagged (trunk) or untagged (access).
2. Layer 3 interface configuration - the IPv4 subnet bound to each VLAN, and the static routes that connect subnets to a next-hop router.
3. Firewall / IP rules - the stateful inspection rules that permit (or deny) traffic across the security zones the S615 defines.

A one-way ping is almost always caused by one of the following:

Cause A: Default gateway missing or wrong on the far-end device

If a PLC, HMI, or PG on VLAN 2 has its default gateway set to anything other than 10.13.180.140 (the S615's VLAN 2 IP), its reply to a ping from VLAN 1 will be sent to the wrong router and will never reach 192.168.55.x. Even with a perfectly configured S615, the end device must know to send return traffic via the S615. A PLC that uses 0.0.0.0 as gateway (a common Siemens default for S7-1200/S7-1500 in subnet-routed mode) will simply not reply to off-subnet traffic.

Cause B: Missing or asymmetric static route

By default, the S615's static route table is populated only from the directly connected subnets. If a third subnet (an upstream corporate network, for example) is involved, a static route must be added under Layer 3 > Static Routes. Per the SCALANCE S615 Getting Started, this is configured with destination network 0.0.0.0 (i.e. default route), subnet mask 0.0.0.0, and the next-hop set to the upstream router's IP. Without it, return packets for traffic the S615 originated into VLAN 1 may be blackholed if a more-specific route does not match.

Cause C: Firewall rule blocking the return path

The S615 is a stateful firewall. The default rule set on a fresh device typically permits traffic from the lower-security zone to the higher-security zone (LAN -> DMZ) and blocks the reverse. A rule must be defined that explicitly allows traffic from the PLC zone (10.13.180.0/24) to the SCADA zone (192.168.55.0/24) for the protocols you need: ICMP for ping, TCP 102 for S7/ISO-on-TCP, UDP 161/162 for SNMP, UDP 67/68 for DHCP relay, UDP 34964 for PROFINET, and so on. On firmware V6.2 and later these are configured under Security > Firewall > IP Rules; on older V4.x firmware the same logic is implemented under Security > Stateful Inspection with a different rule syntax.

Cause D: Default gateway on the VLAN 2 interface pointing at itself

Setting Default gateway: 10.13.180.140 on the S615's own VLAN 2 interface is a recurring misconfiguration. The S615's own interface does not need a default gateway pointing at itself; that field is used by the S615's own IP stack to select a next hop for traffic the S615 itself originates (e.g. NTP, syslog, SNMP traps, firmware check). A gateway pointing at a directly connected subnet is harmless in most cases, but when the address is the S615's own interface IP, the S615 may attempt to ARP for itself and produce erratic return-path behavior, especially under load. Best practice: leave the field empty when no upstream router exists on that subnet, or point it to the true upstream router if one does.

Cause E: TIA Portal S7 routing is not the same as IP routing

TIA's Accessible devices lookup uses S7 discovery (UDP broadcast / ISO-on-TCP) and traverses the S615 even when the firewall blocks ICMP. TIA online success is therefore not proof that ICMP routing works, and is not proof that HMI tag traffic will work either. Always validate with explicit ping from a host on each side, and with an HMI tag poll, not just TIA's online view.

3. Prerequisites

• SCALANCE S615 hardware with firmware V6.2 or later. Current shipping firmware is V7.2; legacy V4.x firmware uses a different WBM layout (SINEMA RC integration moved under System > SINEMA RC, and the firewall is configured under IP Rules rather than Stateful Inspection). Match the WBM path to your firmware revision.
• Admin access to the WBM. Default user is admin, default password admin; change on first login.
• A PC on each subnet for end-to-end verification, with administrative rights to change IP settings and disable the local Windows firewall for the test (or open ICMPv4 inbound on the test PC's profile).
• TIA Portal V15.1 or later if S7 routing is also being validated (independent of the routing issue, but commonly co-deployed in the same troubleshooting session).
• Siemens PRONETA (free download) or a comparable scanner to enumerate reachable nodes on each side without depending on the S615's routing path.

Official references used in this article:

• SCALANCE S615 Operating Instructions (BA_SCALANCE-S610_76)
• SCALANCE S615 Getting Started (GS_SCALANCE-S615_76)

4. Step-by-Step Configuration

4.1 Confirm VLAN membership (Layer 2 > VLAN)

Open the WBM and navigate to Layer 2 > VLAN > General and Layer 2 > VLAN > Port Based VLAN. Verify:

• The port(s) facing the SCADA switch are tagged members of VLAN 1 (or untagged with PVID = 1).
• The port(s) facing the PLC switch are tagged members of VLAN 2 (or untagged with PVID = 2).
• The CPU/internal port is an implicit member of all VLANs (no configuration needed).

If a port is not a member of the VLAN, frames on that VLAN are dropped at Layer 2, and the S615 will appear to "not have" that subnet on that interface. On a tagged trunk, the connecting switch must also be configured to tag the same VLAN ID; a mismatch is a common field issue.

4.2 Configure Layer 3 interfaces (Layer 3 > IPv4 > Subnets)

Navigate to Layer 3 (IPv4) > Subnets and create or edit the entries as follows:

Interface	VLAN	IP address	Subnet mask	Default gateway (on this interface)
vlan1	1	192.168.55.1	255.255.255.0	Leave empty
vlan2	2	10.13.180.140	255.255.255.0	Leave empty

The Default gateway field on each interface should be empty unless the interface actually faces an upstream router on a third subnet. If both VLANs are directly connected to the S615, no static route is required for traffic between them; the S615 derives the routes from the connected subnets. The reported configuration that set Default gateway: 10.13.180.140 on the VLAN 2 interface should be cleared.

4.3 Add a static route if an upstream router is involved

If the SCADA side (VLAN 1) has a corporate uplink to a 10.x or other subnet that the PLC side must reach, add a default route under Layer 3 (IPv4) > Static Routes:

• Destination network: 0.0.0.0
• Subnet mask: 0.0.0.0
• Next hop: 192.168.55.254 (or the actual upstream router on VLAN 1)
• Interface: vlan1

Verify under Layer 3 (IPv4) > Static Routes that the route is active and the admin status is up. A route with admin status down will not appear in the FIB, even if the configuration is saved.

4.4 Create firewall IP rules (Security > Firewall > IP Rules)

The S615 inspects traffic between zones. By default, the two VLANs are in the same Internal zone and traffic passes, but if you have already moved one of them to a separate zone (e.g. DMZ), you must create explicit rules. Recommended rule set for bi-directional ICMP and S7 communication:

Action	Source	Destination	Service	Log
Accept	192.168.55.0/24 (SCADA)	10.13.180.0/24 (PLC)	icmp, iso-tsap (102), TCP 102	No
Accept	10.13.180.0/24 (PLC)	192.168.55.0/24 (SCADA)	icmp, iso-tsap (102), TCP 102	No
Drop	any	any	any	Yes

The S615's firewall is stateful, so a single rule in each direction is technically redundant: return traffic for an established session is auto-permitted. Explicit rules in both directions are easier to audit and survive firmware upgrades that reset default behaviors. Place the deny-all rule last; the S615 processes rules top-to-bottom and stops at the first match.

4.5 Set the default gateway on every end device

For each PLC, HMI, PG/PC, and SCADA server:

• On VLAN 2 (PLC) devices: Default gateway = 10.13.180.140 (S615 VLAN 2 IP).
• On VLAN 1 (SCADA) devices: Default gateway = 192.168.55.1 (S615 VLAN 1 IP) - unless an upstream router is the true gateway.

On a Siemens S7-1200/S7-1500, verify in TIA Portal under Device configuration > PROFINET interface > Ethernet addresses > IP protocol. The default gateway is the field the PLC uses to reach off-subnet destinations, including the SCADA HMI. Without this, even a perfect S615 configuration will not deliver return traffic to the right router.

4.6 Disable or scope IP masquerading if enabled

Under Security > Firewall > IP Masquerading (or NAT on firmware V7.x), verify that masquerading is either disabled or correctly scoped. Masquerade rules that translate 10.13.180.x to 192.168.55.x for outbound traffic can break reply handling if the rule set is asymmetric, or if the masquerade is applied to traffic that should be routed, not NATted. For in-plant inter-VLAN traffic, masquerading should be off; use it only for traffic exiting the S615 toward an ISP or a third-party network that cannot route your internal subnets.

5. Verification

Run the following checks in order, recording the result of each:

5.1 Same-subnet sanity

From a PC on VLAN 1, ping another device on VLAN 1 (e.g. the S615's VLAN 1 IP 192.168.55.1):

ping 192.168.55.1

Expected: reply. If this fails, the issue is in the local subnet, not the S615's routing.

5.2 Cross-subnet from VLAN 1

From a PC on VLAN 1, ping the S615's VLAN 2 IP and a known VLAN 2 host:

ping 10.13.180.140
ping 10.13.180.10

Expected: both reply. If the S615 IP replies but the PLC does, the S615 is routing correctly and the issue is between the S615 and the VLAN 2 host (cabling, switch, PLC IP, PLC default gateway).

5.3 Cross-subnet from VLAN 2 (the failing direction)

From a PC on VLAN 2 (or from the PLC's PG port), ping the S615's VLAN 1 IP and a known VLAN 1 host:

ping 192.168.55.1
ping 192.168.55.50

Expected: both reply. If this is the direction that was failing, the fix is one or more of: clear the self-pointing gateway on VLAN 2, set the correct gateway on the VLAN 2 host, add the ICMP firewall rule, or fix the upstream default route.

5.4 TIA Portal accessible devices

From a PG on VLAN 1, open TIA Portal > Online > Accessible devices. Devices on VLAN 2 should appear, with their actual IP address 10.13.180.x even though the PG is on 192.168.55.x. This confirms S7 routing through the S615. This is a routing test, but it is not an ICMP routing test.

5.5 HMI tag refresh

From a WinCC Unified or TIA WinCC HMI on VLAN 1, force a tag refresh against a VLAN 2 PLC and confirm the value updates within the configured acquisition cycle. If tags update but ping fails, the firewall is allowing S7 (TCP 102) but blocking ICMP; add the ICMP rule to the firewall set.

5.6 Long-run stability

Leave a continuous ping running for at least 24 hours:

ping -t 10.13.180.10 (Windows)
ping 10.13.180.10 (Linux, with shell loop)

Watch for ICMP sequence gaps, which often indicate firewall state-table aging or S615 CPU load issues at high packet rates. The S615 has a state-table size limit (default ~4,096 entries on V6.x firmware, ~16,384 on V7.x); exceeding it drops new flows silently.

5.7 Wireshark / packet capture on the S615

Use Information > Diagnostics > Packet Capture in the WBM. The S615 can mirror traffic from any VLAN to its internal CPU port and export a Wireshark-compatible .pcap. Run the capture while reproducing the failure to confirm whether the S615 is dropping, NATting, or forwarding the traffic. Look for TCP RST or ICMP type-3 (Destination Unreachable) packets emitted by the S615, which indicate a firewall or routing decision.

6. Troubleshooting Matrix

Symptom	Likely cause	Where to look	Fix
Ping VLAN 1 -> VLAN 2 OK, VLAN 2 -> VLAN 1 fails	End device default gateway missing or wrong	Device TCP/IP settings, ipconfig /all, IPCFG on PLC	Set default gateway to S615 IP on the device's own subnet
Ping VLAN 1 -> VLAN 2 fails, TIA can browse VLAN 2	ICMP blocked by firewall, S7/ISO allowed	Security > Firewall > IP Rules	Add Accept icmp rule in both directions
Both pings fail, WBM still reachable from VLAN 1	VLAN 2 port not member of VLAN 2, or PVID mismatch	Layer 2 > VLAN > Port Based VLAN	Set PVID and tag/untag membership correctly
Both pings fail after firmware update	Default rules reset, IP rules wiped	Security > Firewall > IP Rules, pre/post config diff	Re-export backup config, reapply IP rules
Intermittent ping, high CPU on S615	Firewall logging enabled on hot rules	Information > Diagnostics > Log Table, CPU load	Disable log on accept rules, raise CPU load threshold
Ping works, TCP connections (HMI tags) fail	Firewall blocks TCP but allows ICMP, or vice versa	Wireshark on each side, S615 packet capture	Add rules for the specific TCP port (e.g. 102 for S7)
Works in lab, fails in plant	Cabling / PVID mismatch on field switch, duplex issue	Physical layer check, S615 port statistics	Force 100 Mbit/s full-duplex on S615 and field switch port
PLC reachable, HMI cannot resolve DNS name	DNS server on far side unreachable, no UDP 53 rule	Security > Firewall > IP Rules, nslookup from HMI	Add UDP 53 rule; configure DNS server IP on HMI
PROFINET names not resolving	PROFINET DCP (UDP 34964) blocked, LLDP not forwarded	Information > Diagnostics > Log Table, LLDP neighbors	Add UDP 34964 rule, enable LLDP forwarding on S615
SNMP walks from NMS on VLAN 1 fail to S615	SNMP ACL on S615, or UDP 161 blocked	System > Management Access > SNMP	Add NMS IP to SNMP ACL, allow UDP 161 in firewall
NTP sync fails from VLAN 2 devices	No UDP 123 rule, or NTP server on far side unreachable	System > Time > NTP, Security > Firewall	Add UDP 123 rule, set NTP server IP on devices
TIA online works, but PG cannot browse in TIA's project view	PROFINET/PROFIsafe discovery blocked, or S7 routes wrong	TIA project > Online > Accessible devices, S7 routing config	Add UDP/TCP 34964, 102, fix PG routing

7. Common Pitfalls and Field-Proven Caveats

7.1 Self-pointing default gateway on the S615's own interface

On the SCALANCE S615 WBM, the Default gateway field under Layer 3 > IPv4 > Subnets > [interface] applies only to traffic the S615 itself originates (NTP, syslog, SNMP, firmware check, SINEMA RC). It does not push a gateway to end devices. Configuring it to the S615's own IP is a no-op for return traffic from end devices and confuses the routing table under load. Leave it empty when the next hop is a directly connected subnet; point it to the actual upstream router only when one exists.

7.2 TIA Portal S7 discovery is not a routing test

UDP broadcast and ISO-on-TCP discovery packets can leak through the S615 in ways that ICMP cannot. Always validate with explicit ping from a host on each side, not from TIA's Accessible devices panel. TIA success is necessary but not sufficient.

7.3 Firmware upgrades reset firewall rule sets

Always back up the configuration under System > Load & Save > HTTP/FTP/TFTP before any firmware change. Document the rule-count and rule-set diff post-upgrade. On V6.x -> V7.x upgrades, Siemens has changed the IP rule syntax; a rule that worked on V6.x may fail silently on V7.x and need re-creation.

7.4 Spanning Tree and loops

If you connect the S615 to two switches that are also interconnected, you can form a Layer 2 loop. Either enable RSTP on the S615 ports (default: on) and on the field switches, or use a single uplink per VLAN. A loop will saturate the S615's CPU and break all routing and firewall functions within seconds.

7.5 Asymmetric routing with NAT

If you enable IP masquerading for one direction (e.g. SCADA -> PLC) but not the other, the PLC's replies will arrive with an unexpected source IP, breaking connection tracking. Either enable symmetric NAT or, preferably, disable NAT entirely for in-plant inter-VLAN traffic.

7.6 DNS and NTP

If your HMIs and SCADA use a name server or NTP source on the other side of the S615, the firewall must allow UDP 53 and UDP 123, and the end devices must have the right default gateway or DNS server IP. A common field issue is a PLC time wrong complaint that is actually a firewall / DNS / gateway issue.

7.7 Multicast and broadcast

PROFINET, S7 multicast, and many SCADA discovery protocols rely on Layer 2 multicast. The S615 forwards multicast only if IGMP snooping is configured and the relevant multicast groups are permitted. For PROFINET, enable LLDP and verify the PROFINET multicast MAC range (01:0E:CF:00:00:00 to 01:0E:CF:00:07:FF) is not filtered. PROFINET DCP discovery uses UDP 34964; PROFINET real-time uses the same MAC range.

7.8 Duplex and speed

The S615 defaults to autonegotiation. If the field switch port is hard-coded to 100 Mbit/s full-duplex, autonegotiation on the S615 will fail and the link will be down or half-duplex. Symptoms are extreme: a few pings succeed and the rest time out. Force the S615 port to match under Layer 2 > Ethernet > Ports, or leave both sides on autoneg.

7.9 Time and certificates

Firewall log entries are timestamped; an unset system clock makes post-incident forensics painful. Configure NTP under System > Time and verify the S615's time is within a few seconds of the SCADA server. TLS certificates for the WBM and for SINEMA RC will not validate if the system time is more than a few days off.

8. Security Notes

• Change the default admin password on first login. The default admin/admin credential is a documented issue on every S615 firmware version to date and is scanned for by internet worms within hours of deployment.
• Disable unused services. Under System > Management Access, disable Telnet, HTTP (if HTTPS is available), SNMPv1/v2c, and any unused IP services.
• Restrict the WBM to the SCADA side (or a dedicated management VLAN). Do not expose WBM on the PLC side; the PLC network is generally considered less trusted.
• Export the running configuration under System > Load & Save and store it in a version-controlled location after every change. Diff against the last good config to detect unauthorized modifications.
• Enable syslog forwarding to a central SIEM. The S615's Information > Diagnostics > Log Table is volatile across reboots; syslog preserves it.
• Use the built-in VPN for traffic leaving the plant. The S615 supports IPsec and OpenVPN profiles configured under Security > VPN. Avoid exposing port forwarding or 1:1 NAT to the internet.
• Document the firewall rule set as a spreadsheet (rule #, source, destination, service, action, owner, change date). The S615's WBM rule list does not support comments and is hard to audit at scale.

9. Related Configuration and Adjacent Issues

9.1 SCALANCE S615 + SINEMA RC

If the S615 is managed centrally by SINEMA RC, the management connection uses a dedicated tunnel. Verify under System > SINEMA RC that the tunnel is up; if the tunnel is down, you will not be able to push configuration from the central server. A common failure mode is the SINEMA RC server being on a third subnet that the S615 cannot reach because the upstream default route is missing.

9.2 SCALANCE S615 as DHCP server or relay

The S615 can act as a DHCP server for a VLAN or as a relay to a central DHCP server. Under Layer 3 > IPv4 > DHCP, configure the pool or relay. A common field issue is the DHCP server on VLAN 1 not handing out addresses to VLAN 2 clients because the relay IP is wrong or the firewall blocks UDP 67/68 between VLANs.

9.3 SCALANCE S615 as NTP server

The S615 can serve NTP to clients on each VLAN. Under System > Time > NTP, enable the NTP server. Add the NTP service (UDP 123) to the firewall rule set between VLANs if you want clients to use the S615 as a server across VLANs. Many S7-1500 PLCs use the S615 as their NTP source.

9.4 Port mirroring and diagnostics

Under Layer 2 > Mirroring, the S615 supports port mirroring for diagnostic capture. Combine with the packet-capture function to feed Wireshark remotely. This is invaluable for diagnosing asymmetric routing and firewall issues.

10. FAQ