Fix STATUS_IPSEC_CLEAR_TEXT_DROP 0xC0360007

You're remoting into a client's file server, or maybe a SQL box, and the connection just dies mid-session. Event Viewer on the server shows STATUS_IPSEC_CLEAR_TEXT_DROP with code 0xC0360007. The Windows Firewall with Advanced Security log fills with entries like "IPsec dropped an inbound clear text packet" and the source IP is your workstation. Nobody changed anything. Except somebody did — usually a GPO pushed a new connection security rule last night, or an admin half-configured IPsec on one side of the link and walked away.

What's actually happening

IPsec has two modes for traffic: it can require encryption, or allow it. When a policy says "require" and a packet shows up unencrypted, the receiving end has two choices. Drop it, or let it through and log it. STATUS_IPSEC_CLEAR_TEXT_DROP means Windows dropped it. The packet arrived as plain TCP or UDP, but the IPsec policy on the box expected an encrypted (ESP) packet matching a specific security association.

Picture it this way. You put a bouncer on the door who was told "only let people in who show the secret handshake." Then your own delivery guy walks up without it and gets turned away. That's the error. The policy is doing exactly what it was configured to do — the config itself is the problem.

The most common real-world trigger I see: someone sets up a domain isolation GPO scoped to a subnet, but misses one server. Or a laptop gets moved from a corporate VLAN to a guest VLAN and the IPsec policy still applies but the domain controller it authenticates to is unreachable. The Kerberos auth fails, no SA ever forms, and every packet comes in as clear text and gets dropped.

Confirm it's IPsec before you start changing things

Open Event Viewer on the machine receiving the drops and check:

Applications and Services Logs
  └ Microsoft
     └ Windows
        └ Security-Kerberos
        └ Windows Firewall With Advanced Security
           └ Firewall

You want the Windows Firewall With Advanced Security → Firewall log. Filter for Event ID 5152 or 5157. If you see source IPs that should be talking to this box but no Security Association (Main Mode / Quick Mode events), that's your smoking gun. netsh advfirewall monitor show mmsa will also show you what SAs exist right now — if the list is empty for the peer you care about, IPsec never came up.

The fix, step by step

Find the policy. On the machine doing the dropping run:
```
netsh advfirewall monitor show consec
netsh advfirewall consec show rule name=all
```
If it's domain-joined, check what GPO is pushing IPsec:
```
gpresult /h gpreport.html
```
Look under Computer Configuration → Windows Settings → Security Settings → Windows Firewall with Advanced Security.
Decide which side is wrong. Either the sender should be encrypting and isn't, or the receiver shouldn't be demanding encryption from that sender. In 95% of the cases I've dealt with, the receiver's rule is too broad. A domain isolation rule that says "require encryption from all addresses" when it should say "require encryption from the Domain Isolation zone" is the usual culprit.
Fix the connection security rule. In wf.msc, go to Connection Security Rules. Find the rule matching the direction and remote address that's causing the drop. Either:
- Change "Require authentication for inbound and outbound connections" to "Request authentication for inbound and outbound connections" — this is the graceful one. It still tries IPsec but won't drop clear text.
- Narrow the Remote IP address scope so it only matches machines that actually have the IPsec policy.
- If the peer genuinely should be encrypting, fix the peer's outbound rule instead. Don't loosen the receiver.
If it's a GPO-scoped policy and you can't touch the rule, exempt the specific host. Add the peer IP to the rule's "Exempt" list, or add a higher-priority allow rule scoped to that specific remote address. Higher priority means lower number in the rule list. Firewall processing is top-down.
Apply and flush.
```
gpupdate /force
netsh advfirewall firewall set rule group="all" new enable=no
netsh advfirewall firewall set rule group="all" new enable=yes
```
That toggle forces the firewall service to reload rules without a reboot. If you can afford the reboot, just reboot — cleaner.
Verify the SA comes up.
```
netsh advfirewall monitor show mmsa
netsh advfirewall monitor show qmsa
```
You should see the peer's IP with a valid SA. Then re-run whatever traffic was failing and watch the Firewall log. If 5152s stop appearing, you're done.

If it still fails

Three things to check next.

One: inbound versus outbound asymmetry. Half the time the receiver's rule is fine and the sender's outbound rule is what's not requesting encryption. Check both ends. netsh advfirewall consec show rule name=all on the sender tells you what it thinks it should be doing.

Two: certificate or Kerberos breakage. If your IPsec policy uses certificate auth and the cert expired on one peer, the SA negotiation silently fails and every packet falls through as clear text, which then gets dropped. Look for Event ID 4653 or 5451 in the Security log. For Kerberos, check that both machines can reach a KDC and that time is synced within 5 minutes. I've seen a misconfigured NTP server cause IPsec to fail on an entire subnet.

Three: NAT in the path. IPsec doesn't love NAT. If there's a router doing NAT between your two peers and it's not doing NAT-Traversal properly, the IKE negotiation dies at phase 1 and nothing ever gets encrypted. Run Get-NetIPsecMainModeSA in PowerShell — if the SA state is stuck in "Negotiating" or "Failed", it's a phase 1 problem, not a packet problem.

The fix isn't mysterious once you know where to look. Someone configured "require" where they meant "request," and your traffic is the casualty. Find the rule, loosen it or fix the peer, done.