Hello,

I am currently investigating the network behavior of CODESYS 3.5 (IDE + Gateway) in environments where the engineering workstation is connected to a very large /16 network.
In such networks, the automatic device scan performed at IDE startup (and the manual “Scan Network” device discovery) can cause significant delays or freezes, due to the broadcast‑based discovery mechanism.

After analyzing the traffic with Wireshark, I identified that the IDE uses the following UDP ports:

1740 – broadcast discovery

1741 – handshake / responses

1742 – fallback discovery

1743 – fallback handshake

22350 – additional runtime / gateway communication (WAGO, debug, extended discovery)

To prevent the IDE from scanning the large /16 network, I tested blocking these ports in both directions (IN/OUT) on the network interface connected to the /16 segment (while keeping them open on the OT /24 network interface).

Result:

When UDP 1740, 1741, 1742 and 1743 are blocked on the IT interface, the IDE no longer sends any discovery traffic on that interface.

The IDE still works normally on the OT interface (device discovery, online mode, download, etc.).

Blocking port 22350 does not seem required to stop the scan, but I included it for completeness.

My question:
=> Can you confirm that blocking UDP ports 1740, 1741, 1742, 1743 (and optionally 22350) on a specific network interface is a valid and supported way to completely disable the CODESYS IDE network scan on that interface (both at startup and during manual device discovery)?

I am not trying to block communication with controllers on the OT network — only to prevent the IDE from scanning the large /16 IT network.

Any confirmation or additional technical details about the discovery mechanism would be greatly appreciated.

Thank you.