Setting up an OPC UA client to an S7-1516-3 PN/DP, TIA V17, OPC UA server enabled on the CPU, endpoint opc. removed link From a laptop on the plant subnet UaExpert connects, browses, reads, no complaints.
From the KEPServerEX host on the office subnet, 10.10.2.40, the OPC UA Client driver gives BadConnectionClosed, and UaExpert on the same box says connection refused, straight away, no timeout.
I trusted the office box's certificate in the CPU as well, set the policy to None for a test and rebooted the CPU, same every time. IT says the office to plant rule is in place because Kepware already talks S7 to that CPU on port 102 from the same host. Is the CPU refusing anything that isn't on its own subnet? Or is 4840 a separate rule from 102 and IT have only ever done the one?
What does the CPU's certificate list say about the office client, trusted or rejected? An untrusted cert gets bounced fast too, might be that. And is the office host's cert the same one you trusted, or did Kepware make a new one when you changed the policy?
Both certs sit in Trusted on the CPU, checked twice. And with policy None there's no cert exchange at all and it still refuses. Server log line from the driver: "Unable to connect to opc. removed link , BadConnectionClosed". Same line whether the cert's trusted or not, so I'm stuck.
The certificate can't refuse a TCP connection. Certificates are checked after the socket is open, during the OPC UA handshake, and a rejection there reads BadCertificateUntrusted or BadSecurityChecksFailed, not refused. Refused means nothing accepted the TCP connection at all, and immediately, which is a firewall that rejects rather than drops. One question. From the office host, does TCP 4840 open? Test-NetConnection 10.20.7.5 -Port 4840 in PowerShell.
TcpTestSucceeded False from the office host. True from the plant laptop. Port 102 from the office host, True. So the rule IT wrote must be for 102 only, from the last ticket, and I guess they read it as "office to PLC is open".
OPC UA is its own port, 4840 by default, and a rule for S7 on 102 says nothing about it. Ask IT for one rule, TCP 4840 from 10.10.2.40 to 10.20.7.5, that host and that CPU, nothing wider. Not the office subnet, not any port. If they want the port changed the CPU allows that in the OPC UA server settings, but I'd keep 4840 unless there's a real reason. There's a writeup on the zone and port side here: https://plctr.com/implementing-cybersecurity-measures-for-plc-systems/
IT added TCP 4840, office host to the CPU, one line. The Kepware OPC UA Client driver went to connected inside a minute, 900 tags, no BadConnectionClosed since. Put the policy back to Basic256Sha256 with sign and encrypt, still fine.
Plant firewall rejecting TCP 4840 from the office zone, and the only rule was port 102 from an old S7 driver ticket. One firewall rule for exactly that port, that host, that CPU was all it took. Nothing on the CPU was wrong.
What bugs me is the S7 driver on 102 had worked through that firewall for a year, so I never asked what else was open. Should have started with the port test. Thanks pnina, mira88.
Same trap here, a 102 rule from an old ticket nobody had questioned.