Windows Security Log · Event 5157
Event 5157: The firewall blocked a connection
Windows stopped a connection because no rule allowed it. This is the firewall working, not evidence of an attack — Windows blocks inbound traffic by default, so an internet-connected machine collects these constantly. Its real use is diagnostic: it is the fastest way to find which rule is breaking an application.
Also written as Event ID 51575157 blocked connectionwindows firewall blocked event id
- How oftenFires often
- Vendor calls itAudit Failure
- LogSecurity
- SourceMicrosoft-Windows-Security-Auditing
What it means for you
On a personal computer
Your firewall refused a connection. On any machine connected to the internet this happens all day long, because the whole internet is constantly probing every address. It is the opposite of a break-in — it is the lock holding.
For an analyst
Two distinct uses and it pays to keep them separate. Outbound blocks are a troubleshooting tool: when an application mysteriously cannot reach something, 5157 names the process and the port immediately, which is far quicker than reading rule sets. Inbound blocks are a coverage signal: what you learn is which ports the machine is being probed on, and whether your default-deny posture is actually in force. Do not alert on inbound blocks from the internet unless you enjoy alerting on background radiation.
The fields that decide it
Everything else in the log line is context.
- Application Name
- The process whose connection was refused, as a kernel device path. For outbound blocks this identifies the broken application immediately.
- Direction
- Which way the refused connection was going, and the field that determines what the event means.
-
%%14592 (Inbound)Something tried to reach this machine and was refused. Constant background on any internet-facing host. -
%%14593 (Outbound)This machine tried to connect out and was refused. Far rarer, and usually the sign of a real configuration problem. - Destination Port
- What was being reached for. Inbound blocks cluster on the ports scanners care about; outbound blocks name the service your application needed.
- Source Address
- Where an inbound attempt came from. Internal addresses being blocked repeatedly usually means a legitimate system was never allowed through.
- Filter Run-Time ID
- Which rule did the blocking. Resolve it with 'netsh wfp show state' to find the rule to change — this is the field that turns the event into a fix.
Common questions
Is Event 5157 a sign someone is attacking me?
Usually not. Any machine reachable from the internet is scanned continuously by automated tools, and a firewall that blocks by default produces a steady stream of 5157s as a result. The event proves the firewall is doing its job. What is worth attention is a single source generating a large number of blocks across many ports, which is a deliberate scan rather than background noise.
How do I find out which firewall rule blocked my application?
Take the Filter Run-Time ID from the event, run 'netsh wfp show state' as administrator, and search the XML it produces for that ID. It resolves to the specific filter and, usually, the firewall rule behind it. This is much faster than reading through the rule list, especially on a machine with policy-delivered rules you did not write.
What is the difference between Event 5157 and Event 5152?
5157 comes from the Filtering Platform Connection subcategory and records a connection being blocked. 5152 comes from Filtering Platform Packet Drop and records an individual packet being dropped, which produces far more events for the same activity. If you enabled auditing and are drowning, check whether it is 5152 rather than 5157 that is responsible.
Why would an outbound connection be blocked on my own machine?
Because something added an outbound rule — Windows allows outbound by default, so a block means a rule exists. The usual sources are a security product, a Group Policy firewall baseline, or a third-party firewall layered on top. Outbound 5157s are rare enough that each one usually corresponds to a real, findable rule, which is what makes them useful for troubleshooting.
Read next
- The equivalent of Event 5156: The firewall allowed a connection Permitted connections, the same mechanism recording successes rather than refusals — and vastly noisier.
- Read alongside Event 4625: An account failed to log on Failed logons, which is what an inbound scan produces when it does reach a listening service instead of being blocked.
- The equivalent of Sysmon Event 3: Network connection detected Sysmon's network events, which record connections that were made rather than refused.
- Read alongside Event 4719: The audit policy itself was changed Audit policy changes, which is how these events start or stop appearing without the firewall itself changing.
Vendor documentation
Last reviewed 6 September 2026