Could not open connection to the Host on Port 502 ( host = PLC CP3686)

[arunraj.premraj]

Dear Experts,

I am facing a communication issue between PLCCP3686X and Siemens WinCC scada system. I have no issue in the PLC, no error shows in the PLC logs, Program is running fine.

PLC is sending the field instruments data to SCADA via Modbus TCP/IP protocol using Cluster IP.

HSBY PLC LAN cable is connected in level managed switch and then to SCADA.

scada PC is using cluster IP and everything works fine for about 1year… recently my scada lost communication with PLC cluster IP.

while checking Telnet, it says Could not open the connection to the host, Port 502: Connect Failed.

It looks like something in the network has blocked the 502 port and my scada is not getting the data from PLC.

I have isolated the network switch and connected my laptop directly with a small unmanaged 4 port switch and after a power cycle of both the PLC , my laptop is getting modbus data from plc.

once i connect back to Network switch , after a while the port is blocked again and not data appears in SCADA.

Please refer the wireshark capture on the network switch. (10.85.106.53 is the cluster IP ) ( 10.85.106.22 is the scada IP )

i think the PLC is not responding to the Scada request. after i power cycle the PLC it works for 5 mins and again gets blocked.

Question :

1. Is there any way to track what is blocking the PLC 502 port ,
2. If the port is blocked in network switch , how to unblock it without doing power cycle, 3)Can see any log in the PLC on how and when the PLC port is blocked.

rough network architecture.

[valerio.manenti]

@arunraj.premraj

scada PC is using cluster IP and everything works fine for about 1year… recently my scada lost communication with PLC cluster IP.

everything was working fine for one year and suddenly you lost communication with your SCADA system…mmm…some key information are missing, Have you updated something in the last few days? IT department has updated something?

Form AI:
Yes, a network switch can block port 502 , though its ability to do so depends on whether it is a managed or unmanaged device. Port 502 is the standard port for Modbus TCP, and it is frequently blocked by security features in industrial network environments.

How Port 502 Can Be Blocked

• Access Control Lists (ACLs): Managed switches can use ACLs to filter traffic based on Layer 4 protocols and port numbers. A switch administrator can create a rule specifically to deny traffic targeting TCP port 502.

• Security Services: High-end industrial switches often include integrated firewalls or “advanced threat detection” that may automatically block port 502 if they detect unusual polling patterns, which can be flagged as a potential brute-force attack.

• VLAN Isolation: If devices are on different VLANs and the switch is performing inter-VLAN routing (Layer 3), it can block traffic between those segments on specific ports.

• Managed vs. Unmanaged:

  • Managed Switches: Can actively block port 502 through configuration settings.

  • Unmanaged Switches: Typically cannot block specific ports like 502 because they operate strictly at Layer 2 and do not inspect the TCP/IP headers of the data they pass.

    

Common Reasons for Blockage

• Industrial Security: Modbus TCP is often considered “high risk” because many older PLC implementations lack authentication. IT departments often block this port by default to prevent unauthorized access to control systems.

• Software Firewalls: Even if the switch isn’t the culprit, port 502 is frequently blocked by the Windows Firewall or other endpoint security software on the master or slave device

  Ciao
  Valerio

[alexander.hefner]

Hi,
can you please upload a complete wireshark trace (as zip)?
In a screenshot, we can’t see some maybe interesting details (like mac addresses).

Best case would be having a wireshark trace where the running communication and the breakdown of the communication is included.

[arunraj.premraj]

Hi

Thanks for responding , I understand you want the complete wireshark log from start and end of the incident. i could only capture aftermath of the incident .

Please find attached ZIP of the log file i have shown in earlier screenshot. Kindly check if you get any info out of it mean while i will try to restart the PLC and get the running and port blocked logs.

PLC-SPAN-capture.zip (3.9 MB)

I am no expert in networking but i can see the PLC IP actively rejects the request , dont know why??!!

FYI, Below is the IP i have set in PLC

[alexander.hefner]

@arunraj.premraj, thanks for the wireshark trace!

I had a look into, and I saw following:

• in the trace, there’s a 2nd device with IP address 10.85.106.33 which is communicating with the PLCs cluster IP via port 502 (already existing TCP connection at the beginning of the trace)
• the IP 10.85.106.22 (which is the SCADA panel as I understood) cannot communicate with the cluster IP of the PLC, as long as a communication with 10.85.106.33 is already active (the PLCs denys the connection - I think, because there’s already a connection active)
• There’s one section in the trace (around packet 275517) where the connection with IP 10.85.106.22 is established and working … until 10.85.106.33 get’s active again (around packet 278714), after that, communication with 10.85.106.33 is active and IP 10.85.106.22 is blocked again.
• Additionally, it looks like that from .22 are multiple TCP channels opened on the PLC (I see that 3 different ports are resetted in the last screenshot, when the connection to .22 breaks).

So I think, something in the network has changed, some device was added, ore something else happened in the infrastructure outside of the PLC.
I think the first important question is: who is IP 10.85.106.33 and who is IP 10.85.106.22?

.33 has a Siemens MAC address, .22 has a different one (Hewlett Packard) … is it really wanted that 2 devices are communicating with the PLC? From your description, it doesn’t sounds like that.
And is it a wanted/configured behavior, that multiple streams are opened from .22? It seems that .33 just uses one stream (which I would expect with a single ModbusTCP connection).

Packet from .33

Packet from .22

Running TCP comm. on port 502 with .33

Running TCP comm. on port 502 with .22, breaking as soon as .33 connects:

Best regards!

[arunraj.premraj]

Hi,

Thank you for your time in analyzing the packet. I too have the same doubt why .33 device is requesting the data.

I still have one doubt, is it like PLC cluster IP can only respond to one device .22 ? what if we have a requirement of giving data to multiple device for monitoring the parameters from PLC cluster IP . 53?

Thanks and regards

[alexander.hefner]

Hi,

no, I don’t think that the cluster IP can only communicate with one device - in the part of the wireshark trace where modbusTCP sessions are running, the cluster IP already communicates with 2 devices in parallel: .22 and .33, so I’m pretty sure that’s not the problem.

And, after some more analysis, I can see that both devices .22 and .33 are running several sessions / streams in parallel.
The difference is (at least in the small snapshot of a running communication I can see in the trace), that the device .22 sometimes does it in a way I would expect and that is wanted when using TCP: it opens a stream (TCP SYN), queries some modbus data, and then closes the connection (TCP FIN).
For example like here:

But in some other streams, I can see that this is not happening, and the PLC .53 sends a RST flag after some time where the stream is idle (no data flow at all on this stream).
As this always happened after 5 seconds of stream idle, I assume it’s the “device idle timeout” configured in the PLCs modbusTCP stack. (that was also the same situation in the screenshot of my post above, when .33 started communication)
For example here:

And: the device .33 opens some other parallel streams, but doesn’t end that streams in a way that I would expect (I haven’t seen any TCP FIN in all of the .33 initiated streams!) - instead of ending the stream by FIN, the device .33 just sends a RST flag.
For example here:

All in all, because of the combination of all things mentioned above, I could imagine that the PLC comes into some ressource bottleneck after some time with the handling of all of those parallel sessions, where some of them aren’t closed in the way TCP expects it (because all of these sessions have to have handled by the PLC in a way TCP defines the communication flow, and the number of TCP handles is limited inside a PLC).

This bottleneck could lead to the situation, that somewhen all TCP handles of the PLC / all reserved handles for server port 502 are blocked which would then lead to the situation, that no more connections are possible (until reboot).

For me, the questions are:

• who is .33, and why does it not close the sessions in a TCP-usual way?
• why are parallel TCP streams from the same device are querying the PLC server, is that neccessary / reconfigurable?
• what has changed since it does not work anymore? As long as you haven’t changed software on the PLC and it ran for a year or so, I think there must have been some change in the network (for example introducing device .33?), in the firmware of the communication partners (have there been software changes / upgrades on the SCADA device for example), or somewhere else in the infrastructure → even if the PLC is not responding anymore after some time, I’m relatively sure that the PLC is not the root cause but some change in network / in the number of devices / in the devices behavior (that’s what I interprete out of the wireshark trace).
• I don’t think that it’s directly linked to this issue, nevertheless I want to mention it: in the complete trace, I see a very high amount of so-called ARP requests (requests for the MAC address behind of a IP address) for a dedicated small number of IP addresses, much more then I would expect (97% of all captured packages are arp requests).
  • most of that requests (87.4% of all arp requests) are sent by a HMS device (10.85.106.41), is that the switch? Or is there some permanent network / IP scanner running or something like that?

I think that’s more or less everything that can be interpreted out of the wireshark trace.

Best regards.