SCALANCE S615 VPN Status PENDING: China NTP Troubleshooting

1. Problem Summary

A fielded SCALANCE S615 (MLFB 6GK5615-0AA00-2AA2) configured as a VPN gateway with NTP synchronization against time.windows.com operates correctly during commissioning, then drops connectivity to the central VPN endpoint and reports tunnel STATUS = PENDING in Web Based Management (WBM). Diagnostic pings from the S615 to the public NTP server succeed, but the IPsec/IKE negotiation never advances to ACTIVE. The unit is installed behind a Chinese ISP, and this exact failure mode is reproducible across multiple Chinese provinces.

The two symptoms are tightly coupled:

• VPN tunnel stuck in PENDING – IKE phase 1 or phase 2 never reaches QM_IDLE / SA_INSTALLED.
• NTP from time.windows.com may be intermittent or blocked at the GFW layer, causing certificate validity and IKE timestamp failures.

2. SCALANCE S615 Hardware and Firmware Baseline

The SCALANCE S615 is a DIN-rail mounted industrial security appliance combining a 4-port managed switch, stateful firewall, NAT, and IPsec/OpenVPN gateway. The specific variant in this scenario is:

Verify the exact firmware load before troubleshooting. Navigate to System > Information in WBM and record:

• Software version (e.g., V6.5.0)
• Hardware version (e.g., 1)
• Bootloader version
• VPN configuration set / profile name

Known firmware-related improvements that affect VPN behavior across the GFW:

Always reference the official SCALANCE S615 product support page for the current firmware download, release notes, and HSP (Hardware Support Package) for TIA Portal.

3. What "STATUS = PENDING" Actually Means

The S615 VPN state machine reports the tunnel lifecycle as one of four values in Security > VPN > Connections:

PENDING specifically means the S615 sent IKE packets (UDP 500 or 4500) to the configured peer IP, but did not receive a valid reply within the IKE timeout window (default 30 s, retry count typically 5). It is the IKE equivalent of a TCP SYN with no SYN-ACK.

This must be distinguished from:

• Certificates rejected – tunnel briefly enters NEGOTIATING then drops back; check Log > Security for IKE_AUTH failed.
• Phase 2 mismatch – Phase 1 completes, Phase 2 fails (proxy-ID, PFS, lifetime mismatch).
• DPD failures – tunnel was ACTIVE, now drops, often transient.

4. China-Specific Network Constraints

Mainland China operates extensive deep-packet-inspection infrastructure colloquially known as the Great Firewall (GFW). Three behaviors directly impact IPsec and NTP from an S615 deployed behind a Chinese ISP:

4.1 UDP 500 and UDP 4500 Throttling

IKEv1 and IKEv2 use UDP 500 for ISAKMP and UDP 4500 for NAT-Traversal. GFW nodes frequently apply:

• Session rate limiting on outbound UDP 500 above ~1 packet/sec.
• Bidirectional reset injection (RST) when payload patterns match ESP/ISAKMP fingerprints.
• Asymmetric filtering – outbound UDP 500 is allowed, inbound UDP 500 from a non-China peer is silently dropped after a few attempts.

4.2 ESP Protocol (IP 50) Blocking

Native IPsec ESP (protocol number 50) is often blocked at the ISP edge. The S615 must be configured to force NAT-Traversal encapsulation (UDP 4500) rather than relying on ESP, or the tunnel will never establish regardless of IKE success.

4.3 NTP and DNS Interference

time.windows.com is hosted on a CDN with China-edge nodes, but UDP 123 NTP traffic has been intermittently throttled since 2014. More importantly, DNS resolution of time.windows.com can be poisoned, returning IP addresses that are either unreachable or routed through GFW inspection points. The S615 NTP client uses the system DNS resolver configured under System > DNS.

4.4 ICMP and TLS DPI

ICMP echo (used by the WBM ping tool) is normally allowed but is often deprioritized. TLS 1.2/1.3 to commercial CDNs (used by OpenVPN control channels and Siemens SINEMA RC) is generally permitted, but traffic patterns matching corporate VPN signatures can be flagged.

5. Root Cause Decision Tree

Walk the following diagnostic tree before changing any configuration. Each step is observable from WBM or from a PC in the same network segment as the S615.

6. Diagnostic Procedure on the S615

1. Connect to WBM. Point a browser at https://<S615 LAN IP>. Default is 192.168.214.1 on P2/P3/P4 zone.
2. Verify time. Navigate to System > Information and check the device clock. If it is drifting or stuck at 2010, NTP is failing.
3. Verify NTP configuration. System > Time > NTP – confirm server is time.windows.com (or replace) and that the NTP server is reachable from the WAN side. The S615 sends NTP from the WAN interface IP, not the LAN.
4. Check VPN state. Security > VPN > Connections – note state, last error, last transition timestamp.
5. Review the security log. Log > Security > Browse – filter for IKE events around the time the tunnel last went PENDING.
6. Trigger a manual reconnect. Some firmware versions require a Reboot of the S615 to clear stale IKE SAs. Do not full-reset.
7. Capture packets. Plug a mirror tap on P1 (WAN) and run a packet capture for 60 seconds. Filter for isakmp and esp.

7. Solution: Configuration Changes

Apply the following changes in the order given. Each is reversible.

7.1 Force NAT-Traversal (UDP 4500) and Disable Native ESP

In Security > VPN > Connections > Edit > Phase 1:

• Mode: Aggressive or Main – both work, Aggressive is more tolerant of dropped packets.
• NAT-Traversal: Force (not "Detect"). This encapsulates ESP in UDP 4500, bypassing ESP blocking.
• DPD (Dead Peer Detection): Enable with delay 30 s, timeout 120 s.

7.2 Replace time.windows.com with a China-Reachable NTP Source

Do not rely on foreign NTP servers in mainland China. Use one of:

Configure under System > Time > NTP with poll interval 64 s and at least two servers for redundancy.

7.3 Switch to OpenVPN over TCP 443

When UDP-based IPsec cannot be made to work, the S615 OpenVPN client (firmware ≥ V6.0) supports TCP transport. Configure the profile under Security > VPN > OpenVPN:

• Transport: TCP
• Port: 443 (matches HTTPS, almost never blocked)
• TLS auth: Enabled (default)
• MTU: 1300 (avoid fragmentation across GFW nodes)

The central endpoint can be a commercial OpenVPN Access Server, a pfSense/OPNsense box, or a Siemens SINEMA Remote Connect server.

7.4 Adjust MSS and MTU

GFW middleboxes occasionally drop or fragment large UDP packets. In Interfaces > WAN > MTU set:

• Interface MTU: 1400
• TCP MSS clamping: 1360 (under Security > Firewall > Advanced)

7.5 Use SINEMA Remote Connect as Managed Broker

Siemens SINEMA Remote Connect (MLFB 6GK1720-1AH01-0BV0 server, with S615 as SINEMA RC client) is the recommended architecture for plants in restrictive jurisdictions. The S615 establishes an outbound TLS 443 connection to the SINEMA RC server, which then brokers the connection to engineers. Because all traffic is HTTPS over TCP 443, it is largely indistinguishable from web traffic at the GFW layer.

Configuration steps:

1. On SINEMA RC server, create a remote-partner entry for the S615 and download the auto-config package.
2. On S615, Security > VPN > SINEMA RC – import the package; the S615 will pull its VPN config from the broker.
3. Verify tunnel state in SINEMA RC console.

8. Architectural Fix: Bridging IPC427E for PCU/PLC Reachability

The field report raises a secondary problem: the S615 WAN is connected through an IPC427E acting as a routing/boundary node, and the customer PCU/PLC sit on a different subnet (192.168.214.0/24) that needs to be reachable through the S615 once the VPN is up.

On the IPC427E, enable routing between its X2 (toward S615) and X3 (toward PCU) interfaces. Two methods:

8.1 Network Bridge (Windows)

New-NetBridge -Name "BrS615ToPCU" -InterfaceAlias "X2","X3"
# Or via ncpa.cpl: select both adapters, right-click, Bridge Connections

8.2 netsh Routing

netsh interface ipv4 set interface "X2" forwarding=enabled
netsh interface ipv4 set interface "X3" forwarding=enabled
netsh routing ip add persistentroute 192.168.214.0 255.255.255.0 "X2"

Then on the S615 add a static route for the PCU subnet pointing to the IPC427E X2 address as the next hop.

9. Verification Procedure

1. NTP verification: In WBM System > Time confirm "Synchronized" and offset < 1 s. Issue show ntp in CLI.
2. VPN verification: In WBM Security > VPN > Connections confirm state = ACTIVE, uptime counting up, bytes in/out increasing.
3. End-to-end ping: From engineering PC at central site, ping 192.168.214.241 (PCU). Expect < 500 ms RTT.
4. TIA Portal reachability: Online > Accessible nodes should show the PLC S7-1500 / ET200SP CPU.
5. Sustained test: Leave tunnel up 24 h; verify no DPD-triggered reconnects in log.
6. Failover test: Disconnect WAN, reconnect after 60 s; confirm tunnel re-establishes within 30 s.

10. Field-Validated Workarounds

11. Security and Compliance Notes

Operating an IPsec VPN endpoint in mainland China carries regulatory implications. Industrial customers should:

• Confirm with the plant IT/OT authority that VPN traffic to the corporate endpoint is sanctioned.
• Document the public IP, peer IP, and ports in use – the S615 Information > Diagnostics > SNMP can export this for audit.
• Rotate the IPsec PSK or reissue certificates on a defined schedule (annually is typical for industrial deployments).
• Use the S615 audit log (Log > Security > Audit) as evidence of access patterns for compliance.

12. When to Escalate

Escalate to Siemens Technical Support (SR – Support Request) when:

• The S615 cannot reach 8.8.8.8 AND 223.5.5.5 from WBM ping (carrier issue, not security appliance).
• Firmware is below V6.0 and cannot be updated remotely due to a PENDING VPN.
• Log shows CERTIFICATE_HAS_EXPIRED with valid NTP and valid local clock – CA chain issue.
• WBM itself becomes inaccessible – requires direct console (serial RJ45 to USB adapter, 115200 8N1) recovery.

Always reference the official SCALANCE S615 product page for the latest manual, release notes, and HSP package when opening a support request.

13. FAQ