Plant's being split into zones with a firewall in the middle. ControlLogix 1756-L83E, 1756-EN2TR at 10.30.1.20 in zone A, Studio 5000 v34. One 1794-AENT rack ended up in zone B on 10.30.2.40 because that panel sits on the wrong side of the wall.
MSGs from the L83E to the zone B controller go through fine, and RSLinx browses zone B from my laptop in zone A. The AENT rack though, yellow triangle, 16#0204 connection timed out, and it pings from zone A at 1ms.
I raised the RPI, inhibited and uninhibited it, swapped the AENT for a spare, and none of that changed a thing, so I'm stuck. IT say 44818 is open both ways and they can see the sessions. What else does I/O want that a MSG doesn't? Is there another port number I should be taking to IT?
Half working through a firewall is odder than fully broken. What was the RPI on that rack before any of this started, and on the Connection tab, is it unicast or multicast? And is it an AENT or an AENTR, they don't behave the same on multicast.
> unicast or multicast
Unicast, always has been. It's an AENT, series B, the old single port one. RPI was 20ms before too and it ran like that for years. I did try 100ms and 200ms and the 0204 comes back after the same few seconds either way, so I'm not sure the rate is anything to do with it.
IT seeing the sessions only tells you TCP 44818 is open. That isn't your I removed link Ask them for the firewall's deny log filtered on 10.30.1.20 and 10.30.2.40, one minute from when you uninhibit the module. A pcap on the zone B side does just as well. I want the protocol and the port on the dropped packets, not somebody's summary of them.
Deny log, one minute from uninhibit:
deny udp 10.30.1.20/2222 to 10.30.2.40/2222, 43 hits
deny udp 10.30.2.40/2222 to 10.30.1.20/2222, 41 hits
Nothing on 44818 at all, that one's allowed. So the connection opens over TCP and then the actual I/O packets are UDP and get binned, which fits the timeout after a few seconds. I guess I'd never thought about what carries the I removed link
Even with the rule I wouldn't leave that rack at 20ms across a firewall. Ping says 1ms, but a firewall adds its own delay under load, and at 20ms with the default multiplier of 4 you've got 80ms before 0204 lands. One busy minute on that box and it drops anyway. If the rack has to stay over there, 50ms or more.
There's your answer, in two log lines. Explicit messaging, your MSGs and RSLinx, is TCP 44818. Implicit I/O is UDP 2222, and some devices use UDP 44818 for unconnected traffic as well. The Forward Open goes through on TCP, the module says connected, then not one I/O packet arrives and it times out with 0204 after RPI times the multiplier.
If the rack stays put, allow UDP 2222 both ways between exactly 10.30.1.20 and 10.30.2.40, plus UDP 44818 for that pair. Better, move the wall so the rack and its scanner sit in one zone. I/O through a firewall is a rule somebody deletes in two years. Longer version of the zoning argument here: https://plctr.com/implementing-cybersecurity-measures-for-plc-systems/
IT allowed UDP 2222 both ways for that one pair on Thursday and the rack went green the moment they applied it. RPI at 50ms like Dave said, no drops over the weekend.
So the firewall rule only ever covered TCP 44818. The I/O packets are UDP 2222 and were getting dropped, every connection opened and then timed out, and the UDP rule for exactly those two addresses fixed it. Longer term the panel gets a second patch back to the zone A switch and the rule comes out again.
Still bugs me that there's a PanelView on that side too and it's been fine on 44818 alone the whole time. I understand why now and IT still don't. Thanks suel, rsdave.