Modbus TCP Port 502 Blocked — How to Open It (Firewall Fix 2026)

Modbus TCP communicates over port 502 by default — this is the IANA-registered port and what nearly every Modbus master and slave device uses out of the box. When a master can't reach a slave, the very first thing to rule out is whether port 502 is actually reachable between the two devices. This guide walks through checking, opening, and testing it across the three places it usually gets blocked: Windows Firewall, routers/NAT, and cloud security groups.

How to Check If Port 502 Is Blocked

Before touching any firewall settings, confirm the port is actually the problem. Run one of these from the master-side machine:

PowerShell (Windows 10/11):

Test-NetConnection -ComputerName 192.168.1.50 -Port 502

Look at the TcpTestSucceeded field. If it says False, something between your PC and the slave is blocking or dropping traffic on port 502.

Command Prompt (legacy):

telnet 192.168.1.50 502

A blank/connected screen means the port is open. "Could not open connection" or a timeout means it's blocked or nothing is listening.

Fix 1: Windows Firewall (Most Common Cause)

If ModbusSimulator or another Modbus tool is running as a slave on the local PC, Windows Firewall's default inbound rules will silently block port 502 unless a rule explicitly allows it.

1. Open Windows Defender Firewall with Advanced Security (search from the Start menu)
2. Click Inbound Rules → New Rule
3. Select Port → Next
4. Select TCP, then Specific local ports: enter 502
5. Select Allow the connection → Next
6. Check the profiles that apply (Domain, Private, Public — match your network type) → Next
7. Name the rule (e.g., "Modbus TCP 502") → Finish

If your master application is also making outbound connections and it's still failing, repeat the same steps under Outbound Rules.

Fix 2: Router / NAT Port Forwarding

If the master and slave are on different networks (e.g., testing a remote device over the internet or across VLANs), port 502 needs to be forwarded through the router or NAT gateway sitting between them:

• Log into the router's admin panel (commonly 192.168.1.1 or 192.168.0.1)
• Find Port Forwarding (sometimes under NAT, Virtual Server, or Applications & Gaming)
• Forward external TCP port 502 to the internal IP and port 502 of the slave device
• Save and, if required, reboot the router

Security note: Modbus TCP has no built-in authentication or encryption. Forwarding port 502 directly to the public internet exposes the device to anyone who finds it. Use a VPN tunnel between sites instead of opening 502 publicly whenever possible.

Fix 3: Cloud Security Groups (AWS / Azure / GCP)

If your Modbus slave simulator or gateway runs on a cloud VM, the platform's security group or network security rule needs an explicit inbound allow rule:

• AWS EC2: Edit the instance's Security Group → Add inbound rule → Type: Custom TCP → Port: 502 → Source: your master's IP (or CIDR range)
• Azure: Network Security Group → Inbound security rules → Add → Destination port: 502, Protocol: TCP
• GCP: VPC firewall rules → Create firewall rule → Protocols and ports: tcp:502

Other Causes to Rule Out

Symptom	Likely Cause	Fix
Connection refused (not timeout)	Nothing is listening on port 502 at that IP	Confirm the slave application is actually running and bound to 502
Works locally, fails remotely	Router/NAT or cloud security group blocking	See Fix 2 / Fix 3 above
Antivirus / endpoint protection installed	Third-party AV firewall overriding Windows Firewall rules	Add the same port 502 allow rule inside the AV's own firewall settings
Custom port configured on the device	Slave device uses a non-standard port instead of 502	Check device documentation and update the master's port setting to match

Test the Fix Without Real Hardware

Once you've opened port 502, you can verify everything end-to-end without waiting on real field devices. Run ModbusSimulator in Slave mode on port 502 on one machine, then point a Modbus master (or the ModbusSimulator Master tab on another PC) at that IP and port 502. If the connection and register reads succeed, your firewall, port forwarding, and master configuration are all correct — the next step is connecting the real device with confidence.

Frequently Asked Questions

What port does Modbus TCP use?

Modbus TCP uses port 502 by default, as registered with IANA. Some devices allow this to be changed to a custom port, but 502 is the standard and what most masters try first.

How do I check if port 502 is blocked?

From a command prompt, run Test-NetConnection -ComputerName <slave-ip> -Port 502 in PowerShell, or use telnet <ip> 502. If the connection fails or times out, port 502 is blocked somewhere between your master and the slave — most commonly Windows Firewall, a router, or a cloud security group.

How do I open port 502 in Windows Firewall?

Open Windows Defender Firewall with Advanced Security, create a new Inbound Rule for Port, select TCP, enter 502 as the specific local port, allow the connection, apply it to the relevant network profiles, and name the rule (e.g., "Modbus TCP 502"). Repeat as an Outbound Rule if the master-side PC also blocks outgoing connections.

Can I test Modbus TCP port 502 without real hardware?

Yes. Run ModbusSimulator in Slave mode on port 502 on one PC (or localhost), then connect a Modbus master to 127.0.0.1:502 or the PC's LAN IP. This confirms your firewall rules, port forwarding, and master configuration all work correctly before you touch real field hardware.

Related Guides

• Modbus Connection Refused — Causes and Fixes — Broader connection troubleshooting checklist
• Modbus Timeout Error — Causes and How to Fix It — When the connection opens but requests time out
• How to Set Up Modbus TCP/IP Communication — Full TCP setup walkthrough
• How to Simulate a Modbus Slave Without a PLC — Test your master before real hardware arrives