Skip to content

Instantly share code, notes, and snippets.

@minanagehsalalma
Created May 6, 2026 16:33
Show Gist options
  • Select an option

  • Save minanagehsalalma/027611005f45ca6f6073a44510fe303b to your computer and use it in GitHub Desktop.

Select an option

Save minanagehsalalma/027611005f45ca6f6073a44510fe303b to your computer and use it in GitHub Desktop.
IDM Permission denied / 10013 on HTTPS downloads: traced root cause and firewall fix

IDM Permission denied / 10013 on every HTTPS download: traced root cause and exact fix

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.

Symptom

  • 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.

What we checked first

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 trace that mattered

The useful evidence came from IDM's own per-download logs, not from generic UI error text.

Here is how the trace was narrowed:

  1. Trigger an IDM download directly from IDMan.exe with a known HTTPS URL.
  2. Read the newest log under %APPDATA%\IDM\DwnlData\....
  3. Compare IDM's result with direct Windows HTTPS tests to the same host.
  4. 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".

Root cause

The machine had explicit outbound firewall block rules for IDM binaries, including:

  • IDM_Block for IDMan.exe
  • IDM_Block_IDMIntegrator64.exe
  • IDM_Block_IDMGrHlp.exe
  • IDM_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.

Exact fix

The repair that worked was:

  1. Reset Windows Defender Firewall policy to defaults.
  2. Re-add explicit allow rules for IDM executables.
  3. 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.com test URL.
  • The 10013 connect denial disappeared.

Reusable fix script

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.ps1

Then retry the IDM download.

Important side effect

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.

Why this works

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.

#Requires -RunAsAdministrator
[CmdletBinding()]
param()
$ErrorActionPreference = 'Stop'
$timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$backupRoot = Join-Path -Path $PSScriptRoot -ChildPath 'idm-firewall-backups'
$runBackupDir = Join-Path -Path $backupRoot -ChildPath $timestamp
$firewallBackup = Join-Path -Path $runBackupDir -ChildPath 'windows-firewall.wfw'
$idmPaths = @(
'C:\Program Files (x86)\Internet Download Manager\IDMan.exe',
'C:\Program Files (x86)\Internet Download Manager\idmBroker.exe',
'C:\Program Files (x86)\Internet Download Manager\IEMonitor.exe',
'C:\Program Files (x86)\Internet Download Manager\IDMGrHlp.exe',
'C:\Program Files (x86)\Internet Download Manager\IDMIntegrator64.exe'
)
function Remove-IdmAllowRules {
Get-NetFirewallRule -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -like 'IDM *' -or $_.DisplayName -like 'Internet Download Manager *' } |
Remove-NetFirewallRule -ErrorAction SilentlyContinue
}
New-Item -ItemType Directory -Path $runBackupDir -Force | Out-Null
Write-Host "Stopping IDM processes..." -ForegroundColor Cyan
Stop-Process -Name IDMan,idmBroker,IEMonitor,IDMGrHlp,IDMIntegrator64 -Force -ErrorAction SilentlyContinue
Write-Host "Backing up current Windows Firewall policy to $firewallBackup" -ForegroundColor Cyan
& netsh advfirewall export $firewallBackup | Out-Null
Write-Host "Resetting Windows Firewall policy..." -ForegroundColor Cyan
& netsh advfirewall reset | Out-Null
Write-Host "Removing any leftover IDM allow rules before recreating them..." -ForegroundColor Cyan
Remove-IdmAllowRules
Write-Host "Restoring explicit IDM allow rules..." -ForegroundColor Cyan
foreach ($path in $idmPaths) {
if (-not (Test-Path -LiteralPath $path -PathType Leaf)) {
Write-Warning "Skipping missing file: $path"
continue
}
$base = [System.IO.Path]::GetFileNameWithoutExtension($path)
New-NetFirewallRule -DisplayName "IDM $base Outbound" -Direction Outbound -Program $path -Action Allow -Profile Any | Out-Null
New-NetFirewallRule -DisplayName "IDM $base Inbound" -Direction Inbound -Program $path -Action Allow -Profile Any | Out-Null
}
Write-Host ""
Write-Host "Repair completed." -ForegroundColor Green
Write-Host "Firewall backup: $firewallBackup"
Write-Host ""
Write-Host "Restored IDM rules:" -ForegroundColor Cyan
Get-NetFirewallRule -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -like 'IDM *' -or $_.DisplayName -like 'Internet Download Manager *' } |
Select-Object DisplayName, Direction, Action, Enabled |
Format-Table -AutoSize
Write-Host ""
Write-Host "Next step: retry the IDM download that was failing." -ForegroundColor Yellow
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment