This note documents a real case where Internet Download Manager showed:
Permission denied. Please check your firewall settings and ensure that IDM has permits to access the Internet.
and the details line pointed at multiple HTTPS hosts on port 443.
The failure looked like a generic IDM networking problem, but the actual root cause was a set of local outbound Windows Firewall block rules targeting IDM's executables.
- IDM failed on multiple unrelated HTTPS hosts.
- The message always ended with
Cannot connect to <host>:443. - Windows itself could still resolve DNS and connect to the same hosts over
443. - Browsers and direct Windows HTTPS requests still worked.
We ruled out the usual false leads first:
- Verified Windows had no manual proxy enabled.
- Verified WinHTTP proxy was direct.
- Added explicit Windows Firewall allow rules for IDM.
- Reinstalled IDM from the official installer.
- Reset IDM's per-user state.
- Verified the failing CDN hosts were reachable from Windows outside IDM.
Those checks changed the environment, but they did not remove the actual failure.
The useful evidence came from IDM's own per-download logs, not from generic UI error text.
Here is how the trace was narrowed:
- Trigger an IDM download directly from
IDMan.exewith a known HTTPS URL. - Read the newest log under
%APPDATA%\IDM\DwnlData\.... - Compare IDM's result with direct Windows HTTPS tests to the same host.
- Inspect active Windows Firewall rules specifically for the IDM executable paths.
What IDM's own log showed:
- DNS succeeded.
- The target IP was resolved correctly.
- IDM created a socket and reached the connect stage.
- The connect path failed with:
Error code = 10013
That is Winsock WSAEACCES, which means the local machine denied the connection for that process.
In the failing case, the IDM log looked like this:
Connecting...
C0:gethost
C0:Found 15.235.34.119
C0:Connecting...
C0:Checking connect, socket = 2340
C0:Except fds set. Error code = 10013
C0:Disconnect.
Permission denied. Please check your firewall settings and ensure that IDM has permits to access the Internet.
That narrowed the problem from "networking in general" to "local policy blocking IDM specifically".
The machine had explicit outbound firewall block rules for IDM binaries, including:
IDM_BlockforIDMan.exeIDM_Block_IDMIntegrator64.exeIDM_Block_IDMGrHlp.exeIDM_Block_IDMBroker.exe
Those rules were active even while allow rules also existed.
Because Windows Firewall block rules take precedence, IDM's outbound HTTPS connections were denied before TLS even started.
The repair that worked was:
- Reset Windows Defender Firewall policy to defaults.
- Re-add explicit allow rules for IDM executables.
- Re-test IDM with a direct HTTPS download.
After that:
- IDM successfully downloaded the official IDM installer over HTTPS.
- IDM also successfully downloaded the previously failing
acek-cdn.comtest URL. - The
10013connect denial disappeared.
The companion PowerShell script in this gist automates the same repair:
- Stops running IDM helper processes.
- Backs up the current Windows Firewall policy.
- Resets Windows Defender Firewall.
- Re-adds allow rules for IDM executables.
- Prints the backup location and the rules it restored.
Run it from an elevated PowerShell session:
powershell -ExecutionPolicy Bypass -File .\fix-idm-permission-denied-10013-firewall.ps1Then retry the IDM download.
Resetting Windows Firewall removes other custom local firewall rules on the machine, not just IDM-specific ones.
That is acceptable when stale or hidden block rules are the actual cause, but it is more invasive than simply adding allow rules.
The error was not caused by DNS, proxy, TLS certificates, or IDM's download engine itself.
The connection was being denied locally by Windows Firewall policy before the HTTPS session could be established.
Resetting the firewall removes the hidden IDM block rules, and re-adding explicit allow rules restores the intended outbound path for IDM.