What Is Modbus TCP Port 502?

Back to Blog

How Port 502 Is Used

A Modbus TCP client establishes an ordinary TCP connection to the server device, and by convention the destination port is 502, the value registered for Modbus. Over that single connection the client sends requests and receives responses, each prefixed with the MBAP header described in the Modbus MBAP header reference, and the transaction identifier in that header lets several requests be outstanding at once.

Because 502 is the default, most devices and drivers assume it, so it is the first port to open in a firewall or map in a NAT rule when connecting a Modbus device across a network boundary. Some devices allow the port to be changed, which can be a small obfuscation measure, but the standard expectation remains 502. Getting a Modbus TCP link working across a network is exactly the kind of task covered in the connect Modbus to cloud SCADA guide.

Why the Default Port Matters for Security

Port 502 traffic is, by default, unauthenticated and unencrypted, so anything that can reach the port can read and, more worryingly, write to the device. This is why exposing port 502 directly to the internet is a serious risk and why network scanners specifically look for open 502 ports as a sign of an exposed industrial device. The broader risk picture and mitigations are laid out in the Modbus security posture and mitigations reference.

The accepted practice is to keep port 502 on a segmented, protected network and reach it through controlled paths rather than opening it at the edge. Where encryption is required, the Modbus organization defines Modbus over TLS on a different registered port, distinct from the plaintext 502, as covered in the Modbus over TLS reference. Treating an open 502 as safe simply because it works is the mistake that leaves industrial devices exposed.

When Port 502 Will Not Answer

The first diagnostic distinction is refused versus timed out, because they mean different things. A connection refused - a TCP reset in response to the connect attempt - means the host is reachable and answering, but nothing is listening on that port, the Modbus service is disabled, the device was configured to a nonstandard port, or its connection limit is already full. A connect timeout means the packets are going nowhere: a firewall silently dropping them, a wrong route, or a NAT rule that does not point where you think. A successful ping proves only that ICMP gets through, and firewalls routinely treat ICMP and TCP differently.

Symptom	Usual meaning
Connection refused	Host reachable; service off, wrong port, or connection limit reached
Connect timeout	Firewall dropping traffic, or routing/NAT wrong
Connects but requests get no reply	Wrong unit ID, or a gateway with a dead serial side
Works, then drops under load	Connection limit or an idle timeout in a middlebox
Intermittent across a WAN	NAT translation or firewall state expiring between polls

Work from the inside out: confirm the port setting on the device itself, test a TCP connect from the same subnet to prove the service is alive, then test from across each network boundary in turn until the failing hop identifies itself. When the path crosses address translation, verify the forwarding rule maps the external port to internal 502 on the right host - the mechanics are covered under NAT and firewall traversal.

Connection Limits, Keepalives, and Middleboxes

Embedded Modbus TCP servers accept a limited number of simultaneous connections, and the limit is device-specific - check the manufacturer's documentation, not assumptions. The practical symptom is a refusal that appears only when something else is also connected: a second poller, an engineering laptop, or a half-open session from a client that crashed without closing. Devices reclaim dead sessions on their own schedule, so a poller that reconnects aggressively after a network blip can find its own ghost still holding the slot it wants.

Middleboxes add a second layer of state. Firewalls and NAT devices expire idle connections, so a SCADA client with a long poll cycle can find its session silently dead even though both endpoints think it is open - the next request vanishes into a connection the middlebox no longer recognizes. Enabling TCP keepalive, polling frequently enough to keep the state alive, or reconnecting per poll cycle are the standard mitigations. Behind a gateway that fronts serial devices, remember the TCP side accepting a connection proves nothing about the serial side; requests are serialized onto the shared bus, and a dead RS-485 segment produces exactly the connects-but-never-answers symptom in the table above.

Writing Firewall Rules for Port 502

The rule shape that holds up is narrow on every axis: a specific client address, to a specific server address, on destination port 502, with everything else denied and denies logged. That is the deny-by-default firewall rule pattern applied to Modbus, and it turns the firewall log into an intrusion sensor - any denied attempt to reach 502 from an unexpected source is a finding, not noise. Broad any-to-any rules on 502, usually installed during commissioning to make things work, have a way of surviving into production.

Port-level filtering has a hard limit worth naming: it cannot tell a read from a write. FC03 and FC16 travel over the same connection to the same port, so no port or address rule can enforce read-only access. That enforcement takes an industrial firewall that parses the protocol and filters on function codes, described under DPI-based command filtering, layered on top of the OT network segmentation that keeps port 502 out of reach of anything untrusted in the first place.

Frequently Asked Questions