Multiple NICs, Wrong Route: Fix Windows Routing Without Reinstalling

The mental model: how Windows actually picks a route

Windows routing decisions look chaotic until you treat them like a scoring system. For each destination, Windows chooses the “best” route based on:

1. Longest prefix match: a /32 beats a /24 beats a /0. Specific routes win.
2. Route metric: lower is preferred.
3. Interface metric: if multiple routes tie, the interface metric can be the tie-breaker.
4. Next hop reachability: if the gateway isn’t reachable, Windows can move on (sometimes after timeouts that feel like a small eternity).

The most common multi-NIC failure is boring: someone put a default gateway on two adapters. Now there are two 0.0.0.0/0 routes, and Windows picks one based on metrics. If those metrics are automatic, Windows may change its mind after link speed changes, driver updates, VPN posture, or a cosmic ray flipping a bit in the UI. (Okay, maybe not the cosmic ray. Probably.)

There’s also a second failure mode that looks like routing but is actually name resolution: Windows picks the “wrong” DNS server for a query, gets an internal address back, and then routing does exactly what you told it to do. So you troubleshoot the route table for two hours while the DNS client quietly ruins your day.

What “multi-homed” should mean in a sane design

A multi-homed Windows server is fine when each NIC has a clear job:

• One interface has the default gateway for general outbound traffic.
• Other interfaces have no default gateway and use specific static routes (or dynamic routing if you’re that kind of organization).
• DNS is configured deliberately, not copy-pasted across adapters like a ritual.
• Traffic is validated with capture and real application tests, not vibes.

If your design deviates from that, you can still make it work. But you’ll be paying “complexity interest” every patch Tuesday.

One quote worth keeping near your runbooks: “Hope is not a strategy.” — General Gordon R. Sullivan. It’s not a networking quote, but it lands accurately in operations.

Joke #1: Windows routing isn’t haunted; it’s just doing exactly what you configured, and it’s judging you for it.

Fast diagnosis playbook (first/second/third)

This is the “walk in half-awake at 2 a.m.” flow. You’re not here to admire packets. You’re here to stop the bleeding.

First: confirm the wrong path, don’t assume it

• Check the active route to a real destination (your DC, your file server, your monitoring endpoint).
• Confirm which interface is used and which gateway.
• Confirm whether it’s routing or DNS (name resolves to where?).

Second: find the competing defaults and metrics

• Look for multiple 0.0.0.0/0 routes.
• Check interface metrics and whether they’re automatic.
• Check whether a VPN client injected routes or changed metrics.

Third: apply the minimal safe fix

• Remove default gateway from the non-default NICs.
• Set explicit interface metrics (stop letting “Automatic” make policy decisions).
• Add persistent routes for the specific subnets that belong on the other NIC.
• Re-test the application path, not just ping.

If you do those three steps, most “Windows picked the wrong NIC” incidents end quickly. The rest are DNS, WFP/firewall policy, or virtualization weirdness, which we’ll cover.

Interesting facts and context (why Windows behaves like this)

• Fact 1: Windows has supported automatic interface metrics for a long time; it often correlates “faster link” with “better route,” which is not always what you want for policy routing.
• Fact 2: “Binding order” used to be a big deal in older Windows networking stacks; today it matters less for pure routing, but it can still affect some legacy behaviors and name resolution preferences.
• Fact 3: Windows can maintain multiple default routes; the winner is the one with the lowest combined metric, not the one you intended.
• Fact 4: VPN clients frequently add routes and adjust metrics to enforce tunnel preference. Some do it politely, others do it like they pay rent.
• Fact 5: SMB Multichannel exists and can use multiple NICs simultaneously when configured and when the network supports it. That’s great—until you accidentally force SMB onto the management NIC with mismatched DNS.
• Fact 6: “Dead gateway detection” can cause Windows to switch away from a gateway after failures, which can look like random route flapping when one path is intermittently broken.
• Fact 7: Hyper-V vSwitch and vEthernet adapters can introduce additional interfaces that compete for metrics and DNS registration if left on defaults.
• Fact 8: iSCSI guidance has long recommended no default gateway on storage NICs, with explicit routes if needed. People still ignore this, usually right before an outage.
• Fact 9: In enterprise Windows, Group Policy and endpoint agents can change firewall and networking settings after you “fix” them locally, so persistence means understanding the management plane.

Practical tasks: commands, outputs, and decisions (12+)

Every task below includes: a command, what the output means, and the decision you make from it. Commands are shown from a shell. In practice you’ll run these on Windows in PowerShell or CMD; the semantics are what matter. If you’re doing this remotely, do yourself a favor and keep an out-of-band access path.

Task 1: List interfaces and see which ones are up

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name                  Status LinkSpeed MacAddress
----                  ------ --------- ----------
Ethernet0             Up     1 Gbps    00-15-5D-01-02-03
Ethernet1             Up     10 Gbps   3C-EC-EF-10-20-30
vEthernet (Default)   Up     10 Gbps   00-15-5D-AA-BB-CC

Meaning: You have at least three interfaces. Link speed can influence automatic metrics and your assumptions about “preferred” paths.

Decision: Identify which NIC is supposed to be the default (usually management), and which are special-purpose (storage, replication, cluster).

Task 2: Show IP configuration including default gateways and DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,Ipv4Address,Ipv4DefaultGateway,DnsServer"
InterfaceAlias     : Ethernet0
Ipv4Address        : 10.20.30.40
Ipv4DefaultGateway : 10.20.30.1
DnsServer          : {10.20.30.10, 10.20.30.11}

InterfaceAlias     : Ethernet1
Ipv4Address        : 172.16.50.40
Ipv4DefaultGateway : 172.16.50.1
DnsServer          : {172.16.50.10}

Meaning: Two NICs have default gateways. That is the classic “wrong route” generator.

Decision: Unless you intentionally want ECMP-ish behavior (you don’t), remove the default gateway from the non-default NIC and replace it with specific routes.

Task 3: Inspect the routing table for competing defaults

cr0x@server:~$ powershell -NoProfile -Command "route print -4"
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      172.16.50.1    172.16.50.40      5
        10.20.30.0    255.255.255.0         On-link     10.20.30.40    281
       172.16.50.0    255.255.255.0         On-link    172.16.50.40    281
===========================================================================

Meaning: Windows will prefer the 172.16.50.1 default route because metric 5 beats 25. That might be your storage VLAN, not your internet/management VLAN.

Decision: Fix metrics or remove the extra default gateway. Don’t “hope” Windows chooses the other one.

Task 4: Ask Windows which route it would use to a specific destination

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 8.8.8.8 | Format-Table -Auto"
ifIndex DestinationPrefix NextHop       RouteMetric InterfaceMetric
------ ----------------- ------       ----------- ---------------
    12 0.0.0.0/0         172.16.50.1              5              5

Meaning: For that destination, the chosen next hop is on Ethernet1.

Decision: If Ethernet1 is not meant for general outbound, stop it from winning (remove gateway or raise its metric).

Task 5: Check interface metrics and whether they’re automatic

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric,ConnectionState"
InterfaceAlias        InterfaceMetric AutomaticMetric ConnectionState
--------------        -------------- --------------- ---------------
Ethernet1                          5            True Connected
Ethernet0                         25            True Connected

Meaning: AutomaticMetric is enabled; Windows computed these metrics, and it decided Ethernet1 is “better.”

Decision: Disable automatic metrics and set explicit values that reflect intent (not link speed).

Task 6: Set explicit interface metrics (policy beats guesswork)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Ethernet0' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Ethernet1' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50; Get-NetIPInterface -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric"
InterfaceAlias InterfaceMetric AutomaticMetric
-------------- -------------- ---------------
Ethernet0                  10           False
Ethernet1                  50           False

Meaning: Ethernet0 will now generally win ties. This does not remove the second default route, but it changes selection if route metrics line up.

Decision: Still remove the extra default gateway unless you have a real multi-exit design and operational maturity to support it.

Task 7: Remove the default gateway from a non-default NIC

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -InterfaceAlias 'Ethernet1' -DestinationPrefix '0.0.0.0/0' | Remove-NetRoute -Confirm:\$false; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------ ----------------- ------     ----------- -----------
     8 0.0.0.0/0         10.20.30.1          25 ActiveStore

Meaning: Only one default route remains. That’s what you want 95% of the time.

Decision: If Ethernet1 still needs to reach specific remote subnets, add specific routes next.

Task 8: Add a persistent static route for a specific subnet via the secondary NIC

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '172.16.60.0/24' -InterfaceAlias 'Ethernet1' -NextHop '172.16.50.1' -PolicyStore PersistentStore -RouteMetric 5; Get-NetRoute -DestinationPrefix '172.16.60.0/24' | Format-Table -Auto"
ifIndex DestinationPrefix  NextHop       RouteMetric PolicyStore
------ ------------------  ------       ----------- -----------
    12 172.16.60.0/24      172.16.50.1           5 PersistentStore

Meaning: Traffic to 172.16.60.0/24 will go out Ethernet1, regardless of the default route.

Decision: This is how you keep storage/replication paths strict without messing with the global default gateway.

Task 9: Verify DNS server selection per interface and stop “helpful” registration

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet0      {10.20.30.10, 10.20.30.11}
Ethernet1      {172.16.50.10}

Meaning: Ethernet1 has DNS configured. If that DNS namespace isn’t meant for general resolution, you can get “wrong destination” problems that look like routing.

Decision: Usually: only the management NIC gets DNS servers. For isolated networks (iSCSI, backup), set DNS to none and disable dynamic DNS registration on that adapter.

Task 10: Validate name resolution and where it’s coming from

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 1 Name,IPAddress,Server | Format-List"
Name      : fileserver.corp.local
IPAddress : 172.16.60.25
Server    : 172.16.50.10

Meaning: The storage-side DNS server answered and returned an address in the storage/replication range. Now SMB/RDP might try to use that network even if you “fixed routing.”

Decision: Fix DNS: either remove DNS from Ethernet1 or fix split-horizon DNS rules so clients get the correct address for their role.

Task 11: Prove the actual egress interface with a trace (not just ping)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.30.10 -Port 445 -InformationLevel Detailed"
ComputerName           : 10.20.30.10
RemoteAddress          : 10.20.30.10
RemotePort             : 445
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.30.40
TcpTestSucceeded       : True

Meaning: For SMB to the DC/file endpoint, traffic leaves via Ethernet0 with the correct source IP.

Decision: If InterfaceAlias or SourceAddress is wrong, routing and/or DNS is still not aligned with your intent.

Task 12: Check for VPN route injection (the silent contender)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,PolicyStore"
ifIndex InterfaceAlias          NextHop      RouteMetric PolicyStore
------ --------------          ------      ----------- -----------
    22 MyCorpVPN               0.0.0.0               1 ActiveStore
     8 Ethernet0               10.20.30.1           25 ActiveStore

Meaning: Your VPN adapter inserted a default route with metric 1. That’s intentional for full-tunnel VPN; disastrous if you didn’t sign up for it on a server.

Decision: Decide policy: full-tunnel or split-tunnel. Then enforce it at the VPN client configuration level, not by hand-editing routes after every reconnect.

Task 13: Identify persistent routes that will survive reboot (and surprise you later)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Sort-Object DestinationPrefix | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop       InterfaceAlias RouteMetric
----------------- ------       -------------- -----------
172.16.60.0/24    172.16.50.1  Ethernet1                5

Meaning: Persistent routes exist. Good when intentional, awful when forgotten during a migration.

Decision: Audit persistent routes during NIC changes, VLAN changes, and IP renumbering. Treat them like config, not like folklore.

Task 14: Check for IP forwarding (you might have accidentally built a router)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Select-Object -First 5 InterfaceAlias,Forwarding | Format-Table -Auto"
InterfaceAlias Forwarding
-------------- ----------
Ethernet0      Disabled
Ethernet1      Disabled

Meaning: Forwarding is disabled, so this host isn’t routing between networks. That’s the usual server posture.

Decision: If Forwarding is enabled unexpectedly, figure out why. Accidental routing between VLANs can create asymmetric paths and security incidents.

Task 15: Confirm the weak link is not the Windows firewall or policy

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -Auto Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Meaning: Default inbound is blocked, outbound allowed. If your traffic fails only on one interface, profile classification and interface types matter.

Decision: If the “wrong” NIC is classified as Public and policy blocks it, your “routing problem” is actually policy. Fix network category assignment and firewall rules deliberately.

Design rules for multi-NIC Windows that don’t age badly

Rule 1: Exactly one default gateway per routing domain

If your Windows server has two default gateways, it’s not “redundant.” It’s ambiguous. If you need true multi-exit behavior, do it with a router, dynamic routing, or a supported design. Windows is not your edge router. It will try, but it will not be polite about it.

Rule 2: Treat interface metrics as configuration, not a suggestion

Automatic metrics are fine on laptops and end-user desktops. On servers, they’re an outage waiting for the next driver update or link negotiation change. Explicit metrics are cheap stability.

Rule 3: Storage NICs are not “just another NIC”

iSCSI, SMB Direct (RDMA), backup replication, cluster heartbeats: these want predictable paths and predictable source IPs. That means:

• No default gateway
• No DNS servers (usually)
• Disable dynamic DNS registration if it causes client confusion
• Static routes only for the subnets that belong on that fabric

Rule 4: DNS is part of routing, whether you like it or not

When a hostname resolves to an address on the “other” network, Windows will happily send traffic there. Then you stare at the route table wondering why the wrong NIC is used, when the truth is: the destination itself is wrong for that workload.

Rule 5: Virtual adapters deserve the same scrutiny as physical ones

Hyper-V vEthernet adapters, container networking, and VPN adapters can insert routes, DNS servers, and odd metrics. Don’t ignore them because “they’re virtual.” Virtual problems are still real outages.

Joke #2: A second default gateway is like giving your server two steering wheels—technically possible, emotionally regrettable.

Three corporate mini-stories from the routing trenches

Mini-story 1: The incident caused by a wrong assumption

A finance department file server got a second NIC for a new backup network. The engineer doing the change assumed “gateways on both NICs means more resiliency,” because that’s how their home Wi‑Fi mesh behaved. They were not trying to be reckless; they were trying to be helpful under time pressure.

It worked fine during the maintenance window. The backups started. Everyone went home. Overnight, the upstream on the backup VLAN had an intermittent gateway issue—brief packet loss, enough to trigger retries, not enough to fully go down.

By morning, SMB access to the file server was slow for some users and fine for others. RDP into the server was sluggish. Monitoring showed packet loss to random destinations. The team chased storage, then antivirus, then “maybe it’s the switch.” The route table had two defaults, and Windows was preferring the backup VLAN due to automatic metrics. Every time the flaky gateway stuttered, Windows experienced timeouts and eventually failed over to the other default… until it failed back.

The fix was simple: remove the default gateway from the backup NIC, add a route only to the backup target subnet, and set explicit interface metrics. The postmortem was less simple: they updated the build standard so “only one default gateway” was not tribal knowledge but an auditable requirement.

Mini-story 2: The optimization that backfired

A team running Hyper-V hosts wanted faster live migration. They added dedicated 25Gb NICs and set very low interface metrics to “make sure migration uses the fast pipes.” In isolation, that idea sounds reasonable.

What they missed: those same hosts also did domain authentication, patching, and backup coordination, all on the management network. During a busy week, a switch change briefly lowered the negotiated speed on one management link. Automatic metrics recalculated; the “fast migration NIC” started winning more routes than intended. A few services began advertising and reaching out on the wrong source IP.

The failure was subtle. Live migration was indeed fast. But cluster validation started throwing warnings. A management tool intermittently lost contact with hosts. A backup job started connecting to a migration IP that wasn’t reachable from the backup server segment. It looked like random flakiness until someone correlated the times with route changes.

They rolled back the “optimization,” then rebuilt it correctly: no default gateway on migration NICs, static routes where necessary, and SMB Multichannel configured explicitly so migration could use the right interfaces without hijacking the rest of the host’s network identity.

Mini-story 3: The boring but correct practice that saved the day

A manufacturing company had a strict server provisioning checklist. It wasn’t glamorous. It annoyed people who liked “just ship it.” It included explicit interface metrics, a rule of one default gateway, and a small set of persistent routes for replication networks. It also included a routine audit: dump route tables monthly and compare to a baseline.

One month, the audit diff flagged an extra persistent route to 0.0.0.0/0 in the PersistentStore on a domain controller. Nothing had broken yet. That’s the best time to find a failure.

They traced it back to a VPN client test performed by a vendor during troubleshooting. The vendor uninstalled the client, but the route remained. The server would have started preferring that route on the next reconnect of a similarly-indexed adapter or after a metric shuffle. Instead, the team removed the stale persistent route and documented the vendor procedure: no VPN clients on DCs, ever.

The checklist didn’t prevent mistakes. It prevented surprises. In operations, that’s most of the battle.

Common mistakes: symptom → root cause → fix

1) RDP works, but it’s slow and sometimes drops

Symptom: RDP connects, but keystrokes lag; sessions drop during network blips.

Root cause: Two default routes; Windows sometimes uses the “wrong” gateway with intermittent loss.

Fix: Keep one default gateway. Remove 0.0.0.0/0 from the secondary NIC, set explicit interface metrics, and add specific routes for required remote subnets.

2) SMB to a file server goes out the storage NIC

Symptom: File copy uses unexpected source IP; firewall logs show blocked traffic from storage VLAN.

Root cause: DNS resolves the file server name to an address reachable via the storage NIC (or SMB Multichannel picks interfaces you didn’t intend).

Fix: Fix DNS server assignment; make management NIC authoritative for name resolution. If using SMB Multichannel, validate RSS/RDMA NIC roles and ensure client/server subnets align with intended paths.

3) Internet access fails after adding a backup NIC

Symptom: Server can reach internal subnets but not external addresses.

Root cause: Default route moved to a network with no NAT/egress; gateway exists but doesn’t route to internet.

Fix: Ensure the only default gateway is on the egress-capable interface. Add static routes for backup targets instead of adding a gateway.

4) “It worked until reboot”

Symptom: Manual fixes vanish after restart.

Root cause: You edited ActiveStore only; persistent routes/metrics weren’t set, or configuration management overwrote them.

Fix: Use PersistentStore for static routes. Set interface metrics explicitly. Check Group Policy, scripts, and endpoint agents that reapply network settings.

5) Traffic to a remote subnet takes the wrong NIC even with one default gateway

Symptom: Only specific destinations go wrong.

Root cause: A more specific route exists (persistent, VPN-injected, or added by software).

Fix: Find the exact route used with Find-NetRoute, then remove/adjust the competing specific route or set a better metric.

6) After enabling Hyper-V, routes and DNS got weird

Symptom: New vEthernet adapters appear; name resolution changes; default route selection changes.

Root cause: vSwitch adapters are participating in metrics/DNS registration; sometimes the physical NIC becomes a virtual uplink and settings shift.

Fix: Re-audit metrics and DNS on all adapters post-Hyper-V. Disable DNS registration where inappropriate. Ensure the management vNIC is the one with the default gateway.

7) “The gateway is reachable, but apps still fail”

Symptom: Ping works, but SQL/HTTP/SMB times out.

Root cause: Asymmetric routing: replies leave via a different NIC/source IP than the client expects, or firewall state tracking drops it.

Fix: Ensure consistent source IP by correcting route selection and avoiding multiple exits. Validate with Test-NetConnection and packet capture if needed.

Checklists / step-by-step plan (do this, don’t improvise)

Checklist A: Stabilize a broken multi-NIC server in production

1. Identify your intended default interface (management/egress). Write it down so the team stops arguing.
2. Capture current state: adapters, IPs, gateways, DNS servers, route table, persistent routes.
3. Confirm actual route to key endpoints: DC, monitoring, backup target, storage target, internet probe.
4. Remove extra default routes: keep exactly one 0.0.0.0/0 (unless you have a formal multi-exit design).
5. Set explicit interface metrics: disable AutomaticMetric on server NICs; pick stable values (e.g., mgmt 10, storage 50, migration 60).
6. Fix DNS assignment: management NIC gets DNS; specialized NICs usually don’t. Avoid mixing namespaces casually.
7. Add specific persistent routes for remote subnets that must use the secondary NIC.
8. Validate with application-level tests (SMB port 445, SQL port 1433, HTTP health checks). Ping is necessary, not sufficient.
9. Reboot window (if possible) and re-validate. If you can’t reboot, at least ensure the configuration is persistent.
10. Document the intent: which NIC is for what, and what must never be added (like a second default gateway).

Checklist B: Build standard for new Windows servers with multiple NICs

1. Define roles: management, storage, backup, replication, migration, DMZ, etc.
2. One default gateway only, on management/egress.
3. Explicit interface metrics; AutomaticMetric disabled.
4. DNS only on management NIC unless you have a deliberate multi-namespace design.
5. Disable DNS registration on non-management NICs if it causes name confusion in AD-integrated DNS.
6. Persistent static routes for remote special-purpose networks.
7. Monitoring checks that verify source IP for critical flows (catch misroutes early).
8. Change management step: after adding a NIC, re-audit routes and DNS.

Checklist C: When you truly need more than one egress path

This is where teams get creative and then get paged.

1. Decide if the host should do multi-exit routing at all; often it should not.
2. If yes, define policy routing requirements explicitly (which destinations use which egress).
3. Implement with specific routes (and possibly dynamic routing in the network), not “two default gateways and a prayer.”
4. Test failover behavior under loss, latency, and partial outages.
5. Have an operational plan: how you detect path selection, how you roll back, and how you prevent drift.

FAQ

1) Why does Windows pick the “wrong” NIC after I add a second adapter?

Because you gave it two viable routes (often two default gateways) and metrics made the other one cheaper. Automatic metrics can change as link speeds and drivers change.

2) Is it ever okay to configure two default gateways on a Windows server?

Rarely, and only with a deliberate design and testing. If your goal is resilience, do it in the network (routing protocols, redundant gateways), not by giving a server two exits.

3) If I remove the default gateway from the storage NIC, how does it reach anything?

It reaches on-link subnets directly, and anything else via specific routes you add (persistent static routes). Storage networks typically shouldn’t be general-purpose anyway.

4) What’s the difference between route metric and interface metric?

Route metric is tied to a specific route entry. Interface metric is associated with the interface and can influence route preference when multiple routes exist. Lower wins.

5) Why did my “fix” disappear after reboot?

You probably changed ActiveStore routes only, or a management system re-applied settings. Use PersistentStore for routes and set interface metrics explicitly.

6) Can DNS really make it look like routing is broken?

Absolutely. If a hostname resolves to an IP on the secondary network, Windows routes there correctly. The route table is innocent; your name resolution policy isn’t.

7) What about SMB Multichannel—won’t it use all NICs anyway?

It can, if both ends support it and it’s configured. But it doesn’t excuse sloppy gateways and DNS. Validate which interfaces SMB is using and ensure subnets and firewall rules match your intent.

8) Should I disable AutomaticMetric everywhere?

On servers with multiple NICs: yes, typically. On laptops: it’s fine. The difference is that servers are infrastructure; predictability beats convenience.

9) Hyper-V added vEthernet adapters—do they need metrics too?

Yes. Treat them as first-class interfaces. Ensure only the intended management interface holds the default gateway and DNS, and that vNIC metrics don’t unexpectedly win.

10) How do I know which interface Windows will use before I break production?

Use route selection checks (e.g., Find-NetRoute) for representative destinations, then test with Test-NetConnection and validate SourceAddress/InterfaceAlias.

Conclusion: next steps that actually stick

Multi-NIC Windows problems don’t require reinstalling. They require admitting that routing is policy, and policy needs to be explicit.

Do this next:

1. Audit for multiple default gateways and remove extras.
2. Disable automatic interface metrics and set them deliberately.
3. Move special-purpose networks to specific persistent routes.
4. Fix DNS so names resolve to the right network for the job.
5. After any NIC/VLAN/VPN change, re-run the fast diagnosis checks before users do it for you.

If you want one operational habit that pays forever: capture a baseline route table and interface metrics for each server role. When the next “Windows chose violence” incident happens, you’ll have a diff, not a mystery.