What TCP and UDP Ports Does EtherNet/IP Use?

Back to Blog

The Two Ports and Why They Differ

EtherNet/IP splits its traffic across two transports for a reason. Explicit messaging - the request-response traffic that includes connection establishment, browsing, and MSG-instruction reads and writes - runs over TCP on port 44818. TCP gives reliable, ordered delivery, which is what an occasional request and its response need: if a MSG read is briefly delayed or retransmitted, the cost is a small latency, and getting the right answer matters more than getting it in the next millisecond.

Implicit I/O - the cyclic producer/consumer data - runs over UDP on port 2222. UDP has no retransmission and no connection overhead, which is exactly right for real-time I/O: a stale, retransmitted I/O packet is worse than a fresh one arriving on the next RPI. Losing a single cyclic update and getting the next one on time beats delivering the old value late. This is the same reasoning explained in implicit versus explicit messaging, seen from the transport layer.

So the port split maps directly onto the messaging split: TCP 44818 carries the connected and unconnected explicit world, and UDP 2222 carries the cyclic I/O world. Knowing this, a packet capture becomes readable at a glance - traffic on 44818 is setup and explicit messaging, traffic on 2222 is the I/O image flowing.

What the Ports Mean for Firewalls and Diagnostics

For firewall design, the two ports must both be permitted for full EtherNet/IP function, and they are not interchangeable. A rule that opens TCP 44818 but not UDP 2222 produces a classic and confusing symptom: the device is discoverable and explicit messaging works, but no I/O flows, because the cyclic data on UDP 2222 is being blocked. A device that browses fine but will not exchange I/O across a firewall is very often exactly this - TCP allowed, UDP blocked. Any firewall rule set belongs with the OT security team and the site's segmentation standards.

For diagnostics, the port split tells you where to look. If explicit messaging works but I/O does not, suspect the UDP 2222 path - a firewall, or multicast handling if the I/O is multicast. If nothing works at all, suspect the TCP 44818 path first, since connection setup rides there. This is a fast triage that narrows the problem before you touch a cable, and it complements the identity and connection checks in the EtherNet/IP timeout guide.

The Ports Beyond the Big Two

Two more port facts round out the picture. Device discovery - the List Identity broadcast that lets tools find EtherNet/IP devices on a subnet - rides UDP on port 44818, the same number as the TCP explicit port but on the other transport. So a scan tool that finds nothing may be failing on UDP 44818 even though TCP sessions would work fine. And the CIP Security enhancement to the protocol defines secured transport on port 2221, carrying TLS-protected TCP and DTLS-protected UDP traffic for devices that support it; a firewall in front of security-capable devices needs to account for that port as well.

Implicit I/O on UDP 2222 also comes in unicast and multicast flavors, and the difference matters to the network more than to the PLC. Multicast I/O requires the switches to manage group membership with IGMP snooping and a querier; get that wrong and I/O either floods every port or stops dead some time after startup when memberships age out. Modern configurations favor unicast I/O where the devices allow it, precisely because it removes the multicast machinery from the failure surface.

Firewalls, NAT, and Why I/O Breaks Where Browsing Works

When writing rules, think in terms of who initiates. The originator - typically the PLC or scanner - opens the TCP 44818 session toward the target, and the UDP 2222 I/O then flows in both directions between the pair. A stateful firewall therefore needs the TCP session permitted originator-to-target and the UDP exchange allowed both ways. Address translation is the classic trap: the forward-open request that establishes I/O carries IP addresses inside the CIP payload, so plain NAT rewrites the packet headers but not the addresses the protocol actually uses, and the I/O connection fails even though TCP browsing looks healthy. Routed connectivity without NAT, or a gateway that terminates the protocol locally, avoids the problem - one reason edge gateways that poll on the local subnet and push northbound are popular for getting EtherNet/IP data into a cloud SCADA.

The full permit list for a typical cell boundary is short: TCP 44818 for explicit messaging, UDP 2222 both ways for I/O, UDP 44818 if discovery from across the boundary is genuinely needed, port 2221 where CIP Security is in play, and IGMP where multicast I/O exists. Anything beyond that list deserves a named justification, agreed with the OT security team and the site's segmentation standards.

A Worked Triage Sequence

When a device across a boundary misbehaves, the port split turns triage into a fixed sequence:

1. Confirm IP reachability first - if even ping fails (where ICMP is permitted), the problem is routing, not EtherNet/IP.
2. Test the TCP 44818 path; if the session cannot establish, explicit messaging and connection setup are dead, so look at firewall rules and the device itself.
3. If browsing works but I/O is absent, suspect UDP 2222 handling: firewall UDP rules, NAT anywhere in the path, or multicast group management.
4. If I/O starts and later dies on a repeating schedule, suspect IGMP membership timeout or an idle UDP state entry expiring in a firewall.
5. Only then capture packets, filtering on the two ports, with the capture point as close to the boundary as possible.

Each step eliminates a layer, and the port numbers are what make the packet capture readable when you finally take one.

Frequently Asked Questions