Read each port number together with its transport and function

In common, unencrypted EtherNet/IP communication, TCP 44818 carries messaging and connection management, UDP 44818 supports encapsulation services such as device discovery, and UDP 2222 carries implicit I/O data. Saying only “port 44818” is therefore incomplete. Specify TCP or UDP and the function required. Transport protocols and CIP application functions operate at different levels.

TCP 44818: explicit messaging and connection management

Explicit messaging can access supported CIP services for parameter reads and writes, diagnostics or tag access on suitable controllers. In conventional Full EtherNet/IP transport, these operations use TCP 44818. The client establishes a TCP connection and an encapsulation session, then sends CIP requests and processes replies. The distinction between connected and unconnected explicit messaging is different from the choice of whether TCP is used.

TCP 44818 also carries connection management services such as Forward_Open when establishing common I/O connections. The use of UDP for subsequent I/O packets does not remove the TCP requirement during setup. The protocol's connection sequence explains why both kinds of traffic can appear in one system. Check the services supported by the actual device model.

UDP 44818: distinguish discovery from data access

UDP 44818 supports discovery and encapsulation commands such as ListIdentity. Engineering software browsing for device identities is one example. It is inaccurate to describe this port as an interchangeable alternative to TCP 44818 for every parameter read or write.

Discovery broadcasts do not automatically cross into other subnets through normal routing. A device missing from a browse window may therefore still be reachable at its known IP address. Check IP and network configuration, the selected computer interface, VLAN and the discovery method used by the engineering software. Direct address-based access and automatic discovery are different tests.

UDP 2222: cyclic I/O data

UDP 2222 is the principal port for conventional EtherNet/IP implicit I/O traffic. It carries commands, status and process data between suitable scanner and adapter devices. In industrial applications, connections can produce data cyclically or on a change-of-state basis where supported. The relevant data structure is determined during connection setup.

RPI and connection timeouts are separate from the port number. UDP does not provide TCP's retransmission mechanism for lost packets. Timely updates and communication-loss detection depend on the relevant protocol and application mechanisms. Allowing UDP 2222 alone does not guarantee the required performance without assessing latency and update intervals.

Although IANA registers port 2222 for both TCP and UDP, the conventional implicit I/O transport described here uses UDP. Do not interpret every registry entry as a service that must be enabled on every device. Verify actual requirements against the product's port matrix and the connection type used.

Why might allowing only UDP 2222 be insufficient?

For a common, unencrypted Full EtherNet/IP I/O connection, the scanner first establishes the session and I/O connection through TCP 44818. I/O data then travels over UDP after successful setup. If TCP 44818 is blocked in this sequence, allowing UDP 2222 alone is insufficient. Conversely, TCP setup can succeed while a blocked UDP path prevents cyclic data exchange.

Discovery, connection establishment and I/O data transfer are separate checkpoints. Devices using different transport profiles or security capabilities can follow different flows. General port information must therefore be combined with the product manual's connection requirements.

Port 2221 also matters when using CIP Security

Relevant CIP Security profiles use TLS over TCP 2221 and DTLS over UDP 2221. The TCP path can protect UCMM and Class 3 explicit messages; the UDP path can protect Class 0/1 I/O communication and its associated connection management. This does not mean that every EtherNet/IP device supports port 2221 or that all standard ports can be closed unconditionally.

Opening port 2221 alone does not enable CIP Security. Configure endpoint support, credentials and security policy. Assess supported security capabilities and the device's conformance and certification scope separately. Whether secure and standard traffic coexist depends on the architecture in use.

Specify sources, destinations and directions in firewall rules

A rule should identify the source IP, destination IP, TCP/UDP transport, port and communication direction. For example, with PLC 192.168.10.10 and adapter 192.168.10.20, the PLC can initiate a TCP session to destination port 44818 on the adapter. The client's source port may be ephemeral. Do not assume that both source and destination ports at both endpoints must be 44818.

A stateful firewall can track return traffic belonging to an allowed TCP session. Stateless ACLs require separate consideration of the return direction. For UDP I/O, verify actual source and destination endpoints, unicast or multicast selection and the device's connection information. All these flows cannot be covered by treating them as replies to a TCP session.

Design access controls and network segmentation to permit only required devices and functions. A port rule does not automatically distinguish CIP read services from write services. If that distinction is required, assess appropriate application authorization or industrial protocol inspection. Exposing these services directly to the internet should not be used as a commissioning method.

Handle multicast and supporting services separately

If an I/O connection uses multicast, assess group addresses, IGMP snooping and the querier arrangement in the relevant network. IGMP has no TCP or UDP port number; it is carried as a separate IP protocol within IPv4. A rule described as opening a UDP port for IGMP is therefore incorrect. Discovery broadcasts and I/O multicast are also different traffic.

Device web management, address assignment or other applications may need additional services. Assess them according to the features actually used. For example, Modbus TCP is a different application protocol from EtherNet/IP. Its TCP port 502 does not replace EtherNet/IP ports 44818 or 2222. One Ethernet device can support multiple protocols.

Check packet captures and observed symptoms

For authorized network observation, a starting Wireshark display filter is tcp.port == 44818 || udp.port == 44818 || udp.port == 2222. For CIP Security traffic, separately examine tcp.port == 2221 || udp.port == 2221. A port filter selects relevant packets; it does not prove that their contents are valid CIP data or that encrypted contents can be decoded.

During diagnostics, first establish where packets are being captured. An ordinary computer connected to a switch may not see all communication between two other devices. Suitable port mirroring or a network TAP may be needed. A ping reply provides evidence of IP-level reachability, rather than confirmation of TCP/UDP permissions or an I/O connection.

If discovery fails, inspect UDP 44818 and the broadcast path. If session setup fails, inspect TCP reachability and the device service. If a session exists but I/O does not work, inspect the UDP path alongside assemblies, data sizes and connection ownership. A physical connectivity problem or incorrect address can cause similar symptoms. Another service may also occupy a local port; custom client applications should check for local socket binding errors.

Application example: monitoring data and controlling field I/O

A SCADA driver may access supported PLC data through explicit messaging while the same PLC establishes implicit I/O communication with a variable frequency drive. These tasks do not necessarily have identical port and direction requirements. Record actual flows for the application, allow the required communication and check disconnection and reconnection behavior.