1. The Firewall Rule Doesn’t Actually Allow the Inbound Traffic (Most Common)
I know this error is infuriating. You set up a rule — or so you thought — but the connection still gets dropped. This happens more than you’d think. I’ve seen it on Windows 10 Pro, Windows Server 2019, and Ubuntu 22.04.
The typical trigger: you installed a server app (like Apache on port 80 or Minecraft on 25565), but you forgot to create an inbound rule. Or you created one, but it’s disabled. Or worse — you created a rule for the wrong port.
Fix it in Windows:
- Open Windows Defender Firewall with Advanced Security.
- Click Inbound Rules on the left panel.
- Look for a rule that matches your app or port. If you don’t see one, right-click and choose New Rule.
- Select Port, then pick TCP or UDP and type the port number (like 25565).
- Choose Allow the connection.
- Make sure the rule profile matches your network (Private, Domain, Public).
- If the rule exists but still drops, right-click it and Enable it.
A quick way to test: turn off the firewall temporarily. If the connection works, your rule is the problem. Don’t leave it off — just test and turn it back on.
Real-world example: A user on Reddit spent 3 hours trying to join his own Minecraft server. He had created the rule for UDP but the game uses TCP. Double-check the protocol.
2. Another Firewall Profile or Application Is Overriding Your Rule
This tripped me up the first time too. You might have a rule that allows the connection, but another rule — or another firewall — blocks it. Happens a lot on Windows when you have third-party antivirus with its own firewall. Also on Linux if you use both iptables and ufw.
Check for conflicting rules in Windows:
- In Windows Defender Firewall, go to Inbound Rules.
- Look for any rule that blocks the same port or app. Block rules always win over allow rules.
- If you see a block rule, disable it or change its priority.
Check for third-party firewalls:
If you have Norton, McAfee, or Bitdefender, their firewall can block inbound connections even if Windows allows them. Open the antivirus dashboard and look for a firewall section. Temporarily disable it to test.
On Linux (Ubuntu/Debian):
sudo ufw status verbose
This shows all rules. If you see DENY IN for your port, that’s the blocker. Remove it with:
sudo ufw delete deny 25565
Then add an allow rule:
sudo ufw allow 25565
Also check iptables rules if you’re advanced:
sudo iptables -L -n
Look for a DROP or REJECT rule on your port. If you see one, delete it with the rule number.
3. Windows Network Profile Is Set to Public (And You Allowed Only Private)
This one is sneaky. You think you set the rule correctly, but your network is set to Public, and your rule only applies to Private or Domain networks. The firewall drops the inbound connection because the profile doesn’t match.
This happens a lot when you connect to a new Wi-Fi network — Windows labels it Public by default.
Fix it:
- Open Settings > Network & Internet > Wi-Fi (or Ethernet).
- Click the network name.
- Change Network profile type from Public to Private.
- Now go back to your firewall rule and check the Scope tab. Make sure it includes Private.
If you don’t want to change the network type (maybe it’s a public hotspot), you can edit the rule to also apply to Public profiles. In the firewall rule properties, under Advanced, check Public under Profiles.
Pro tip: I always set my rules to apply to all profiles. It’s simpler. Only restrict it if you really need to lock things down.
Quick-Reference Summary Table
| Cause | What to Check | Fix |
|---|---|---|
| Missing or disabled firewall rule | Inbound rules in Windows / ufw / iptables | Create or enable the allow rule for the correct port and protocol |
| Conflicting rule or third-party firewall | Block rules, antivirus firewalls, iptables chains | Disable block rules or add explicit allow rule |
| Network profile mismatch | Public vs Private network type | Change network to Private or edit rule to include Public |
If none of these fix it, check if the service itself is listening. Use netstat -an | grep LISTEN (Linux) or netstat -an | findstr LISTEN (Windows). If the port isn’t showing as listening, the firewall isn’t the real problem — your app isn’t running.