Modbus

Network Ports & Requirements

Port(s)	Transport	Direction	Purpose	DSCP	Multicast	Config.
502	TCP	Both	Classic `Modbus TCP` request/response session. Used by the client to read/write coils and registers in a server device, or in a serial gateway front-ending downstream `Modbus RTU` devices.	—	—	No
802	TCP	Both	`Modbus Security` (`mbaps`) profile. Carries the same `Modbus` application payload inside a secured `TLS` session with certificate-based authentication context.	—	—	No
—	Serial	Both	`Modbus RTU` / `ASCII` field-bus communication. Relevant to cabling, gatewaying, device addressing, baud/framing settings, termination, biasing, and bus discipline, but not to firewall rule sets.	—	—	No

AV500.io

Gotchas & IT Notes

• ⚠Port `502` is the normal `Modbus TCP` service port. Treat it as an internal control/facilities service, not something to expose broadly.
• ⚠IANA registers `mbap` on both `TCP 502` and `UDP 502`, and `mbap-s` on both `TCP 802` and `UDP 802`; the live registry was last updated `2026-05-28` when checked on `2026-05-30`. That registry fact is not a reason to open UDP by default. The official `Modbus Messaging on TCP/IP` guide is a TCP implementation guide, and `Modbus Security` is TLS-based; add UDP only when the specific endpoint/gateway documentation requires it.
• ⚠`Modbus TCP` is typically client-initiated polling. In AV terms that usually means the control processor, BMS gateway, or monitoring server opens the session and the field device behaves as the server.
• ⚠If a TCP device is front-ending serial downstream devices, the `Unit Identifier` field matters for routing to the correct target behind the gateway.
• ⚠Classic `Modbus TCP` is not encrypted or authenticated. If the brief has real security requirements, confirm whether the devices actually support the `Modbus Security` profile on `802` rather than assuming "Modbus over Ethernet" is good enough.
• ⚠`Modbus Security` exists, but the installed base is still heavily classic `502`. Mixed estates are normal, and secure deployment requires certificate provisioning and operational ownership.
• ⚠`Modbus RTU` has no IP port footprint. Do not write firewall requirements for it; write serial-bus requirements instead.
• ⚠For ordinary AV/facilities firewall schedules, define the allowed client/server pairs and direction explicitly. Avoid broad AV-to-OT any/any rules on `502`; the meaningful path is normally one polling client to one gateway/server, with write capability separately approved.
• ⚠Avoid connection churn in polling loops. The official TCP/IP guide recommends keeping a TCP connection open with a remote device and using a minimum number of TCP connections; low-end gateways and field devices may have small connection limits.
• ⚠Modbus is a polling/supervisory protocol. If the integration brief expects rapid unsolicited event streaming, granular subscription models, semantic alarms/trends/schedules, or internet-facing remote management, this is the wrong protocol family.
• ⚠Multiple `Modbus TCP` clients against one endpoint are not guaranteed. Confirm session limits and count AV control, BMS, monitoring, commissioning, and vendor service tools before assuming everything can poll at once.
• ⚠Serial gateway performance is often the hidden bottleneck. A TCP socket to the gateway can be healthy while the downstream `RS-485` trunk is overloaded, misaddressed, mistimed, unterminated, or stuck behind a slow/offline server.
• ⚠The commissioning deliverable is a points list, not a protocol checkbox: function code, register/coil address, zero-based versus human reference notation, read/write rights, units, scaling, signedness, byte/word order, polling interval, timeout behavior, stale-value handling, and gateway/offline behavior.
• ⚠Do not give AV systems write authority to facility plant by accident. Use named read-only points by default and require explicit approval for every writable register or coil, especially around HVAC, electrical distribution, generators, transfer switches, and life-safety-adjacent systems.
• ⚠If a Modbus TCP gateway fronts serial devices, document the `Unit Identifier` / downstream-address mapping, serial trunk baud/framing, retry and timeout policy, stale-value behavior, and whether the gateway caches responses. TCP reachability to the gateway is not proof that the downstream device is live.
• ⚠For remote service, do not expose classic `TCP 502` directly because the traditional profile has no authentication or encryption. Use segmentation and approved remote-access architecture; use `Modbus Security` on `802` only where the selected endpoints and operational owner can support certificate lifecycle.
• ⚠Treat every writable Modbus path as an approved OT control path, not a convenience feature. The firewall rule should name the polling client, server/gateway, point purpose, write permission, and owner of the register schedule.
• ⚠Modbus is not a substitute for BMS/SCADA trending, alarms, or historian functions. If facilities need analytics or operator workflows, AV should consume a curated subset of points rather than become the system of record.