The client says it cannot connect, the server window looks fine, and nothing is actually broken. Windows Firewall is doing its job - it just has not been introduced to iperf3 yet.
You start the server with iperf3 -s, run the client, and get a connection error. Before you blame cables, understand this: an iperf3 server is a program listening for incoming connections, and Windows Firewall blocks unknown listeners by default. That is correct behaviour. This guide shows the safe way to let your own test through - on your private network only - and how to remove the permission when you are done.
Windows Defender Firewall has blocked some features of this app.
Allow iperf3.exe to communicate on:
[x] Private networks, such as my home or work network
[ ] Public networks, such as those in airports and coffee shops
iperf3 listens on TCP port 5201. The client reaches out, which firewalls generally allow, but the server has to accept an incoming connection, which they do not - not until you say so. So the usual symptom is one-sided: the server window sits there looking peaceful while every client fails to connect.
The fix belongs on the server PC. Allowing iperf3 on the client alone changes nothing, because the client was never the one being blocked.
The first time you run iperf3 -s, Windows usually shows a Security Alert asking which networks iperf3 may use. Tick Private networks and leave Public networks unticked, then click Allow access.
That distinction is the whole safety story. Your office LAN and home network are private - the test belongs there. A public profile means coffee-shop and airport networks, where a listening program has no business being reachable. If your test still cannot connect after allowing, check that both PCs actually classify the network as Private in Windows network settings - a network marked Public will keep blocking even an allowed app in some configurations.
Sometimes the prompt was dismissed once, or never shows. Then add the permission yourself: open Windows Defender Firewall with Advanced Security, choose Inbound Rules, then New Rule. Pick Program, browse to iperf3.exe, choose Allow the connection, and apply it to the Private profile only.
A port rule for TCP 5201 works too and is what many admins prefer, because it survives replacing the iperf3 folder. Either way: Private profile, your network, nothing wider.
On a managed office PC, the prompt may never appear and the firewall may be locked by policy. Do not fight the policy - it is protecting the company, and honestly, it is doing exactly what it should.
Your options, in order: run the server on a machine you administer and test from the locked PC as the client - clients are rarely blocked. Swap the roles and compare both directions that way. Or ask IT to allow port 5201 between the test machines for an afternoon. And when testing ends, delete the rule you added. A forgotten open listener is how small conveniences become real holes.
The complete iperf3 setup and live testing, step by step, in the video.
Watch Full VideoTCP port 5201 by default, for both the control connection and the test data in iperf3. You can choose another port with the -p flag on both sides, but 5201 is the standard and the one to allow in the firewall.
On a private network, for a test you are actively running, yes - with two habits: allow it on the Private profile only, and stop the server (Ctrl+C) and remove the rule when the work is done. iperf3 has no password, so anything that can reach the port can ask it to run a test.
Check that the server window is still open and listening, that you typed the server's correct IPv4 address, and that both PCs are on the same network without a guest Wi-Fi or client-isolation setting between them. Hotel and guest networks often block device-to-device traffic entirely.