Cluster Network Not Internal Error 0X000013C4 Fix

Network role set to Client and Internal when only Internal is allowed

I know this error is infuriating. I've seen it stop a cluster dead in its tracks during a critical deployment. The most common cause is that one or more cluster networks have the role set to Client and Internal when they should be Internal only. This happens a lot when you add a second network after the initial setup and the wizard defaults to the wrong role.

Here's the fix. Open Failover Cluster Manager, go to Networks, find the network showing the error (usually named like Cluster Network 2 or 3), right-click it, and choose Properties. Under the General tab, change the role from Client and Internal to Internal. Click OK. That's it—the error should clear within a few seconds.

If you prefer PowerShell (I do), run this:

Get-ClusterNetwork | Where-Object {$_.Name -eq "Cluster Network 2"} | Set-ClusterNetwork -Role Internal

Replace Cluster Network 2 with the actual name of your problem network. I've used this on Windows Server 2016, 2019, and 2022—it works every time.

Multiple networks accidentally set to Client and Internal

Sometimes only one network is wrong, but I've seen cases where someone configures both cluster networks with dual roles. That's a bigger headache. The cluster needs at least one network for internal heartbeats and data replication, and that network must be strictly Internal. If you set both networks to Client and Internal, the cluster can't decide which one to use for private communication, and you get the 0X000013C4 error.

To check this, run:

Get-ClusterNetwork | Format-Table Name, Role

Look for any network where the Role column shows ClientAndInternal. If you see two or more with that value, pick one (typically your dedicated heartbeat network, often on a separate subnet) and change it to Internal using the PowerShell command above. I recommend leaving the other network as ClientAndInternal so clients can still reach the cluster. Then restart the Cluster Service on all nodes:

Restart-Service ClusSvc

This forces the cluster to renegotiate network roles. I've tripped this up the first time too—don't panic if the error persists for 30 seconds after the restart. Give it a minute.

Network connectivity issues between nodes

If changing roles doesn't fix it, the problem might be physical or logical connectivity. This error can also fire when a cluster network is up but not passing traffic correctly. For example, if you have a VLAN misconfiguration or a switch port in the wrong access mode, the nodes see the network but heartbeat packets drop.

Start by pinging each node's IP on that network from other nodes. Use continuous ping:

ping -t [node-IP]

Let it run for a minute. Look for any Request timed out or intermittent losses. Also check the firewall—Windows Firewall with Advanced Security needs to allow inbound rules for Failover Cluster Virtual Networks. If you're using a third-party firewall, make sure ICMP and the cluster ports (UDP 3343, TCP 445, TCP 135, RPC dynamic ports) are open on the private network.

One real-world scenario: I once spent four hours on this error in a remote data center only to find that the IT team had plugged the second NICs into the same switch without VLAN separation. The cluster saw both networks on the same broadcast domain and refused to use either for internal communication. We re-cabled to separate VLANs, and the error vanished.

If you suspect a DNS or name resolution issue, check that the cluster nodes can resolve each other's hostnames on the private network. Use nslookup from each node. If resolution fails, add a static entry to the hosts file.

Quick-reference summary table