Laptop with 2 NICs for 2 different subnets but always uses the NIC with prioriy 1

Question

Laptop with 2 NICs for 2 different subnets but always uses the NIC with prioriy 1

Salam ELIAS 302

Hi, I have a laptop and desktop both have 2 NICs, 1 is 1Gbs used for local subnet, the 2nd NIC is 10Gbs I need it for accessing the internet

1 NIC is in a 192.168.1.0/24 attached tothe router which serves as a DHCP and I have a local DNS to server the local subnet as mydns.mynetwork.net.

2nd NIC is in the 192.168.0.0/24 attached to the internet provider box directly (in order to be able to have more than 1Gbs when I browse internet). Here is a snapshot of the network

User's image

DNS for both machines on NIC 1 is my internal DNS in 192.168.1.0/24. With both NICs active, I cant reach any machine in the local subnet 192.168.1.0/24 but when I disable the 2nd NIC everyting goes alright and can ping any machine in local network.

I understand that it is not possible that both NICs have a gateway so NIC 1 is witout gateway but I did a rout add to 192.168.1.0/24 using the router internal IP 192.168.1.1 as the gateway.

when I do a route on the laptop I get

IPv4 Route Table

===========================================================================

Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 30 0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.2 25 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 192.168.0.0 255.255.255.0 On-link 192.168.0.2 281 192.168.0.2 255.255.255.255 On-link 192.168.0.2 281 192.168.0.255 255.255.255.255 On-link 192.168.0.2 281 192.168.1.0 255.255.255.0 On-link 192.168.1.6 281 192.168.1.6 255.255.255.255 On-link 192.168.1.6 281 192.168.1.255 255.255.255.255 On-link 192.168.1.6 281 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 192.168.1.6 281

On the desktop

IPv4 Route Table

Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.182 2 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 192.168.1.0 255.255.255.0 192.168.1.1 192.168.1.3 10 192.168.1.3 255.255.255.255 On-link 192.168.1.3 263 192.168.2.0 255.255.255.0 192.168.1.1 192.168.1.3 8

When I ping desktop (whic has 192.168.1.3 IP )from laptop which has 192.168.1.6 IP , desktop respond with the other subnet IP

User's image

whereas I ping laptop from desktop it also responds on the other subnet NIC but with different behavior

User's image

Am I missing something in NICs configurations?

Thanks for your help

0 comments

2 answers

Your answer

Answer 1

The issue is the routing design, not just NIC priority.

Windows decides whether traffic is local or remote by comparing the destination IP with the local IP and subnet mask. For hosts on the same subnet, traffic is sent directly on-link and does not need a gateway. For remote networks, traffic is sent to a default gateway.

In this setup, 192.168.1.x/24 traffic should stay on the 192.168.1.x NIC and should not be routed through 192.168.1.1 as a gateway. The route on the desktop:

192.168.1.0    255.255.255.0    192.168.1.1    192.168.1.3

is wrong for a directly connected subnet. That subnet should be on-link through the 192.168.1.x interface, not via the router.

Also, having two default routes:

0.0.0.0 -> 192.168.1.1
0.0.0.0 -> 192.168.0.254

causes Windows to prefer the lower-metric default route for non-local traffic. That affects which NIC is chosen for replies and can make the behavior look inconsistent.

Use this configuration instead:

On the 192.168.0.x NIC only, keep the default gateway 192.168.0.254 for Internet access.
On the 192.168.1.x NIC, remove the default gateway.
Do not add a route for 192.168.1.0/24 through 192.168.1.1. Since that subnet is directly attached, Windows should use the on-link route automatically.
Verify both machines have a direct route like this for the local NIC:
```
   192.168.1.0    255.255.255.0    On-link    192.168.1.x
```
If a wrong persistent route was added, delete it and recheck with route print.

Expected result:

Access to local devices on 192.168.1.0/24 uses the 1 Gb NIC directly.
Internet traffic uses the 10 Gb NIC through 192.168.0.254.
Replies to 192.168.1.x peers should come from the 192.168.1.x address, not the 192.168.0.x address.

One more important point: Windows behavior with multiple adapters can be unexpected, especially when routing is nonstandard. Microsoft also notes that multiple adapters do not provide load balancing by themselves, and routing table order determines which adapter is used.

References:

Answer 2

Daphne Huynh (WICLOUD CORPORATION) 1,980 Microsoft External Staff Moderator

Welcome to Microsoft Q&A!

Thank you for taking the time to provide the routing tables and network topology

From the information you shared, having two NICs on different subnets is not necessarily the problem. The main thing I would look at is the routing configuration and DNS resolution.

Windows first uses the most specific route that matches the destination. When there are competing routes with the same prefix length, the route and interface metrics help determine which path is preferred.

In your setup, the intended configuration appears to be:

192.168.1.0/24 NIC: local network access
192.168.0.0/24 10-Gbps NIC: Internet access
The 192.168.0.x NIC: default gateway for Internet traffic

1. You should not need a static route for 192.168.1.0/24

On the laptop, you already have this route:

192.168.1.0 255.255.255.0 On-link 192.168.1.6

This is important because it tells Windows that 192.168.1.0/24 is directly reachable through the NIC with address 192.168.1.6.

Therefore, traffic from 192.168.1.6 to 192.168.1.3 should go directly between those interfaces. It does not need to pass through the 192.168.1.1 router.

Unless 192.168.1.1 is needed to reach a different subnet, such as 192.168.2.0/24, I would remove the manually added route for 192.168.1.0/24.

2. Check the laptop's two default routes

One thing that stands out in the laptop's route table is that there are still two default routes:

0.0.0.0/0 -> 192.168.1.1 metric 30

0.0.0.0/0 -> 192.168.0.254 metric 25

Even though you mentioned that the 192.168.1.x NIC does not have a default gateway configured, the routing table still shows a default route through 192.168.1.1.

I would verify where that route is coming from and remove it if it is not required.

For the design you described, I would aim for the following configuration:

LAN NIC (192.168.1.x)

IP address: 192.168.1.x/24
Default gateway: None
Internal DNS as required

10-Gbps/Internet NIC (192.168.0.x)

IP address: 192.168.0.x/24
Default gateway: 192.168.0.254
Used as the default route for Internet traffic

Afterward, check route print again and confirm that you have only the intended default route through 192.168.0.254.

3. NIC priority alone should not determine local subnet traffic

I would not focus too much on making one NIC "priority 1."

For example, when the laptop sends traffic to 192.168.1.3, Windows already has a specific 192.168.1.0/24 on-link route. That route is more specific than the 0.0.0.0/0 default Internet route.

So, the expected behavior is:

192.168.1.x traffic -> 1-Gbps LAN NIC

Internet traffic -> 10-Gbps NIC -> 192.168.0.254

Interface metrics become particularly relevant when Windows has multiple routes that are otherwise valid candidates for the same destination.

4. Check DNS

The screenshots suggest there may be a second issue involving name resolution.

For example, if you run:

ping desktopname

And the name resolves to 192.168.0.182 instead of 192.168.1.3, Windows will ping the address returned by DNS. Changing the interface metric would not make the hostname resolve to the other address.

I would compare:

nslookup desktopname

With:

ping 192.168.1.3

If ping 192.168.1.3 works but ping desktopname resolves to the 192.168.0.x address, then I would investigate the DNS records and DNS registration of the two adapters rather than adding more static routes.

5. Suggested configuration

Ultimately, I would try to get the routing table to follow this design:

192.168.1.0/24 -> directly connected 1-Gbps NIC

192.168.0.0/24 -> directly connected 10-Gbps NIC

0.0.0.0/0 -> 192.168.0.254 through the 10-Gbps NIC

If another internal subnet such as 192.168.2.0/24 really is reachable through the router at 192.168.1.1, then a specific route for that remote subnet would make sense, for example:

route -p add 192.168.2.0 mask 255.255.255.0 192.168.1.1

After making the changes, I would verify the behavior with:

route print

ping 192.168.1.3

tracert 192.168.1.3

nslookup desktopname

I would start with the direct IP ping because it separates a routing problem from a DNS/name-resolution problem.

The most important detail from the information you posted is that the laptop still shows a default route through 192.168.1.1, despite the intention for that NIC to have no default gateway. I would investigate and clean up that route first, then verify DNS registration if communication by hostname still uses the 192.168.0.x address.

I hope this helps clarify what is happening with the two adapters.

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Salam ELIAS 302 Reputation points

2026-10-12T07:23:17.13+00:00
Thanks Daphne, I removed the 2nd default route from laptop and I was able to ping my DNS. However, on the desktop, I dont have a direct link on 192.168.1.3

Only

192.168.1.3 255.255.255.255 On-link 192.168.1.3 263 192.168.2.0 255.255.255.0 192.168.1.1 192.168.1.3 8 192.168.95.0 255.255.255.0 192.168.1.23 192.168.1.3 8

so can I add a direct link to theis 192.168.1.3? if yes how?
Salam ELIAS 302 Reputation points

2026-10-12T07:48:40.07+00:00
I was able to add a direct link to the NIC wiith 192.168.1.3 on the desktop but still not able to ping it from Laptop. I get

C:\Users\salam.SALAM>ping salam7

Pinging salam7.local [fe80::6b2e:1833:80a4:619d%10] with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for fe80::6b2e:1833:80a4:619d%10:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

salam7.local is the default domain name on the ISP provider box.

In spite of the fact that when I do an nslookup on the desktop for the desktop I get my local dns details

nslookup salam7

Server : salammain.salam.net

Address 192.16.1.13 (my local DNS IP)

Name : salam7.salam.net

Addresses : 2a01:e0a...........

192.168.1.3 192.168.0.182
Daphne Huynh (WICLOUD CORPORATION) 1,980 Reputation points Microsoft External Staff Moderator

2026-10-12T08:58:49.48+00:00
Thanks for quickly update and the additional information.

The latest test is particularly useful:

ping salam7 -4

Resolves salam7.local to 192.168.1.3, but the request times out. At the same time, communication through the 192.168.0.x network succeeds.

This suggests we should separate name resolution from IPv4 connectivity rather than add more routes.

1. First verify whether the desktop really has the 192.168.1.0/24 connected route

You should not normally need to manually create a route to the network to which an adapter is directly connected.

If the desktop's LAN adapter is configured as:

192.168.1.3 Subnet mask: 255.255.255.0

Then, Windows should have an on-link route for 192.168.1.0/24. Windows prefers the longest matching prefix when selecting a route, and route metrics are used when multiple matching routes have the same prefix length.

Please run the following on the desktop:

ipconfig /all route print -4 Get-NetIPConfiguration Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix

For that adapter I would expect to see both its host route and the connected subnet, similar to:

192.168.1.0 255.255.255.0 On-link 192.168.1.3 192.168.1.3 255.255.255.255 On-link 192.168.1.3

The /32 entry for 192.168.1.3 is only the route for the local host address. If 192.168.1.0/24 is still missing, I would check the adapter's IPv4 address and subnet mask instead of adding another static route. A normal /24 adapter configuration should establish the connected subnet.

2. Test the IP address directly

From the laptop, please test the below instead of using ping salam7 for the moment:

ping 192.168.1.3

This is important because it removes DNS, .local, IPv6, and DNS suffix selection from the test.

If ping 192.168.1.3 still times out, name resolution is no longer the immediate issue. The next thing to investigate is whether the ICMP request actually reaches the desktop and whether the desktop permits the request.

Check the active Windows network profile and ICMP firewall rules on the desktop:

Get-NetConnectionProfile Get-NetFirewallRule -DisplayName "*Echo Request*" | Select-Object DisplayName,Enabled,Profile,Direction,Action

Windows Defender Firewall can be configured with an inbound ICMP rule and that the rule can be scoped by network profile and IP address. Therefore, make sure the appropriate ICMPv4 Echo Request rule applies to the profile used by the 192.168.1.3 adapter.

As a diagnostic test, temporarily enabling the applicable File and Printer Sharing (Echo Request - ICMPv4-In) rule is safer than disabling Windows Defender Firewall completely.

Also try from the desktop:

ping 192.168.1.6

If the desktop can reach 192.168.1.6 but the laptop cannot reach 192.168.1.3, that would further point toward filtering or configuration on the desktop rather than a missing route on the laptop.

3. There is also a separate name-resolution issue

Your earlier test:

ping salam7

Resolved to:

fe80::...%10

While:

ping salam7 -4

Resolved salam7.local to: 192.168.1.3

Those are different tests. The fe80:: address is an IPv6 link-local address, whereas -4 forces ping to use IPv4.

Also, your nslookup salam7 result shows that your internal DNS returns multiple addresses for the desktop, including:

192.168.1.3192.168.0.182 and an IPv6 address.

Windows name resolution can return both IPv4 and IPv6 addresses, so the fact that nslookup displays 192.168.1.3 does not guarantee that an ordinary ping salam7 will use that address.

There is another important detail: .local is the suffix being supplied by the ISP-side network, while your internal DNS appears to use salam.net.

I would therefore compare these explicitly:

nslookup salam7.salam.net Resolve-DnsName salam7.salam.net ping salam7.salam.net -4 ping 192.168.1.3

Using the internal FQDN salam7.salam.net avoids mixing the ISP-side .local namespace with the internal DNS namespace while troubleshooting.

4. Check DNS registration on both NICs

Because salam7 has both 192.168.1.3 and 192.168.0.182, I would also verify whether both adapters are registering themselves in your internal DNS.

Run:

Get-DnsClient | Select-Object InterfaceAlias,InterfaceIndex,ConnectionSpecificSuffix,RegisterThisConnectionsAddress

If you only want the 192.168.1.3 LAN address published in the internal DNS zone, review the Register this connection's addresses in DNS setting for the Internet-facing NIC.

After correcting the DNS registration configuration, the DNS client records can be refreshed with:

ipconfig /flushdns ipconfig /registerdns

5. Recommended target configuration

For this design, I would keep the configuration simple:

192.168.1.x LAN adapter

Desktop: 192.168.1.3/24

Laptop: 192.168.1.6/24

No default gateway

Internal DNS as required

Direct 192.168.1.0/24 on-link route created by the adapter configuration

192.168.0.x Internet adapter

Desktop: 192.168.0.182/24

Laptop: 192.168.0.2/24

Internet gateway: 192.168.0.254

The only default route for normal Internet traffic

Keep explicit routes through 192.168.1.1 only for other internal networks that actually sit behind that router, such as your 192.168.2.0/24 network.

I would not add another manual route for 192.168.1.0/24 until the desktop adapter configuration is checked. The key diagnostic result now is whether ping 192.168.1.3 succeeds. Since ping salam7 -4 already resolves to 192.168.1.3 and still times out, adding another DNS entry or changing NIC priority is unlikely to fix that particular failure.

If the problem remains after confirming the /24 adapter configuration, connected route, firewall/profile configuration, and DNS registration, a packet capture on both computers while running ping 192.168.1.3 would be the next useful step. That will show whether the Echo Request reaches the desktop and whether an Echo Reply leaves it.
Salam ELIAS 302 Reputation points

2026-10-12T09:58:22.9333333+00:00
After all changes, when I do a ping to any machine in local subnet I get a reponse that startes with

76.223.54.

I really cant understand where those IPs come from

C:\Users\salam.SALAM>ping salamcogretour

Pinging salamcogretour.salam.net [76.223.54.146] with 32 bytes of data:

Reply from 76.223.54.146: bytes=32 time=3ms TTL=249

Reply from 76.223.54.146: bytes=32 time=5ms TTL=249

Reply from 76.223.54.146: bytes=32 time=3ms TTL=249

Reply from 76.223.54.146: bytes=32 time=4ms TTL=249

Ping statistics for 76.223.54.146:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 3ms, Maximum = 5ms, Average = 3ms

pinging A2nd box

C:\Users\salam.SALAM>ping salam7

Pinging salam7.salam.net [76.223.54.146] with 32 bytes of data:

Reply from 76.223.54.146: bytes=32 time=3ms TTL=249

Reply from 76.223.54.146: bytes=32 time=4ms TTL=249

Reply from 76.223.54.146: bytes=32 time=4ms TTL=249

Reply from 76.223.54.146: bytes=32 time=4ms TTL=249

Ping statistics for 76.223.54.146:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 3ms, Maximum = 4ms, Average = 3ms
Salam ELIAS 302 Reputation points

2026-10-12T12:16:05.9133333+00:00

yes both lap and desktop had 2 records in local DNS for

Desktop 192.168.1.3 and 192.168.0.182

laptop 192.168.1.6 and 192.168.0.2

Which I removed manually.

I rebooted my DNS box as well as those 2 boxes, when I run on laptop (sierac box)

Resolve-DnsName sierac.salam.net

I get

when I do it for salam7 the desktop on the laptop I get

Name Type TTL Section IPAddress

salam7.salam.net A 3600 Answer 13.248.169.48

salam7.salam.net A 3600 Answer 76.223.54.146

when I run the same command on the desktop for the desktop I get the exact same behavior. Local DNS now has only 1 record for each box with 192.168.1 IP. I am not able to understand from where those 2 IPs are coming

In fact, after rebooting the DNS box, I noticed 2 new records for both boxes with IPs from 192.168.0

Salam ELIAS 302

As you mentioned, now configuration are exactly as you laid ou in 5. Recommended target configuration

but still

........\PS\Scripts>

Resolve-DnsName salam7.salam.net

Name Type TTL Section IPAddress

salam7.salam.net A 3044 Answer 76.223.54.146

salam7.salam.net A 3044 Answer 13.248.169.48 Routing table on desktop

     0.0.0.0          0.0.0.0    192.168.0.254    192.168.0.182      2
 192.168.0.0    255.255.255.0         On-link     192.168.0.182    257

192.168.0.182  255.255.255.255         On-link     192.168.0.182    257

192.168.0.255  255.255.255.255         On-link     192.168.0.182    257

  192.168.1.0    255.255.255.0         On-link       192.168.1.3    263

  192.168.1.3  255.255.255.255         On-link       192.168.1.3    263

192.168.1.255  255.255.255.255         On-link       192.168.1.3    263

  192.168.2.0    255.255.255.0      192.168.1.1      192.168.1.3      8

 192.168.95.0    255.255.255.0     192.168.1.23      192.168.1.3      8

Daphne Huynh (WICLOUD CORPORATION) 1,980 Reputation points Microsoft External Staff Moderator

2026-10-13T02:46:10.62+00:00
Thank you for the detailed update and for taking the time to work through all these tests. The good news is that the latest results help narrow the issue down considerably.

At this point, I would not make any further routing changes. The desktop now has the expected directly connected route:

192.168.1.0/24 -> On-link -> 192.168.1.3

And the default route is through:

192.168.0.254 -> 192.168.0.182

This matches the network design we discussed earlier.

The most important finding now is that:

Resolve-DnsName salam7.salam.net

Returns:

76.223.54.146 13.248.169.48

Instead of the expected local address 192.168.1.3.

That also explains why ping salam7 is going to 76.223.54.146. Windows is attempting to contact the address returned during name resolution. Changing the NIC metric or adding another route for 192.168.1.0/24 would therefore not correct this particular behavior.

1. Query the internal DNS server directly

I would first check exactly what your internal DNS server is returning, without relying on automatic DNS server selection.

From the laptop, please run:

Resolve-DnsName salam7.salam.net -Type A -Server 192.168.1.13 -DnsOnly

And:

nslookup salam7.salam.net 192.168.1.13

If these return 192.168.1.3, while:

Resolve-DnsName salam7.salam.net -Type A

Continues to return the public addresses, that would indicate that the normal lookup is not following the DNS path you expected.

If the query sent explicitly to 192.168.1.13 also returns 76.223.54.146 and 13.248.169.48, I would focus the investigation on the DNS server and the salam.net zone rather than on Windows routing.

You can perform the same test for the laptop:

Resolve-DnsName sierac.salam.net -Type A -Server 192.168.1.13 -DnsOnly

Where the expected local A record would be 192.168.1.6.

2. Verify which DNS servers both NICs are using

On both computers, please check:

Get-DnsClientServerAddress -AddressFamily IPv4

And:

ipconfig /all

In particular, check the DNS servers assigned to both adapters.

Because the 192.168.0.x adapter is connected to the ISP network, it is worth checking whether that NIC is also receiving DNS settings from the ISP device.

3. Check DNS registration on the Internet-facing NIC

The fact that the 192.168.0.x DNS records reappeared after you manually removed them is another useful clue.

Windows multihomed clients can register addresses from multiple adapters in DNS. If you only want the internal 192.168.1.x address registered in your internal DNS namespace, check:

Get-DnsClient | Select-Object InterfaceAlias,InterfaceIndex,ConnectionSpecificSuffix,RegisterThisConnectionsAddress

For the Internet-facing 192.168.0.x adapter, review:

Adapter Properties > IPv4 > Advanced > DNS > Register this connection's addresses in DNS

If that adapter should not register its 192.168.0.x address in the internal salam.net DNS zone, disable registration for that connection.

After changing the registration setting, you can remove the unwanted 192.168.0.x records again and retest. Otherwise, manually deleting the records may only be temporary if the adapter subsequently registers them again.

4. Keep the IP connectivity and DNS tests separate

For now, I would test the LAN independently of DNS.

From the laptop:

ping 192.168.1.3

From the desktop:

ping 192.168.1.6

If direct IP communication still fails despite both computers having the correct 192.168.1.0/24 connected routes, that should be treated as a separate LAN connectivity or filtering problem.

The hostname test should then be investigated separately.

5. The reason why are 76.223.54.146 and 13.248.169.48 appearing?

Based on the latest results, those addresses are appearing during name resolution, not because Windows is selecting the 192.168.0.x NIC based on its route metric.

In other words, the important question has now changed from:

"Which NIC is Windows choosing?"

To:

"Which DNS server or resolution path is returning these public addresses for salam7.salam.net?"

The explicit query to 192.168.1.13 should be particularly useful because it isolates the internal DNS server from the normal client DNS selection process.

6. Recommended next step

You have already done quite a lot of troubleshooting, and I truly appreciate the detailed results you have provided.

If the unexpected DNS responses continue after checking the DNS configuration on both NICs, preventing unwanted registration from the Internet-facing adapter, and querying 192.168.1.13 directly, I recommend opening a Microsoft Support request for deeper investigation.

When opening the support case, it would be helpful to include:

ipconfig /all from both computers

route print -4 from both computers

Get-DnsClient

Get-DnsClientServerAddress

Resolve-DnsName salam7.salam.net -Type A

Resolve-DnsName salam7.salam.net -Type A -Server 192.168.1.13 -DnsOnly

nslookup salam7.salam.net 192.168.1.13

The DNS zone configuration for salam.net

The two-NIC topology you shared

Packet captures from the client and DNS server while reproducing the lookup, if available

Since Microsoft Q&A is a public discussion forum, I do not have access to your environment or to the deeper diagnostic information that Microsoft Support can collect and analyze. At this stage, I would avoid making additional routing changes because the routing table now appears consistent with the intended configuration. A support case would be the safer next step if the DNS tests above do not identify the source of the unexpected responses.

I hope this helps narrow things down. You have already resolved an important part of the original routing problem.

The explicit query against 192.168.1.13 is the test I would focus on next, as it should help determine whether those unexpected public addresses are coming from your internal DNS server or from another name-resolution path.

Thank you for your cooperation during this process.
Salam ELIAS 302 Reputation points

2026-10-13T06:44:25.6833333+00:00
Hi, here are my responses

1 - External NICs not registered anymore in internal DNS

2 - Yesterday, all of a sudden I was able to ping desktop from laptop and laptop to dektop but is not the case after starting the boxes this morning

3 -

.....\PS\Scripts> Resolve-DnsName salam7.salam.net -Type A -Server 192.168.1.13 -DnsOnly

Name Type TTL Section IPAddress

salam7.salam.net A 1200 Answer 192.168.1.3

......\PS\Scripts> Resolve-DnsName sierac.salam.net -Type A -Server 192.168.1.13 -DnsOnly

Name Type TTL Section IPAddress

sierac.salam.net A 1200 Answer 192.168.1.6

4 -

.........\PS\Scripts> Get-DnsClientServerAddress -AddressFamily IPv4

InterfaceAlias Interface Address ServerAddresses

Index Family

USB10Gbs 12 IPv4 {192.168.0.254}

Ethernet 4 5 IPv4 {192.168.1.13}

Wi-Fi 3 17 IPv4 {}

Local Area Connection* 9 32 IPv4 {}

Local Area Connection* 10 28 IPv4 {}

Bluetooth Network Connection 30 IPv4 {}

Loopback Pseudo-Interface 1 1 IPv4 {}

vEthernet (USB10Gbs) 37 IPv4 {}

vEthernet (Ethernet 4) 39 IPv4 {}

vEthernet (Wi-Fi 3) 44 IPv4 {}

5 -

PS E:\Salam\Dev\WindowsScripts\PS\Scripts> Get-DnsClient | Select-Object InterfaceAlias,InterfaceIndex,ConnectionSpecificSuffix,RegisterThisConnectionsAddress

InterfaceAlias InterfaceIndex ConnectionSpecificSuffix RegisterThisConnectionsAddress

USB10Gbs 12 home True

Ethernet 4 5 True

Wi-Fi 3 17 True

Local Area Connection* 9 32 True

Local Area Connection* 10 28 True

Bluetooth Network Connection 30 True

Loopback Pseudo-Interface 1 1 True

vEthernet (USB10Gbs) 37 False

vEthernet (Ethernet 4) 39 False

vEthernet (Wi-Fi 3) 44 False

6 - Still pinging using IPs is not working

Laptop to desktop

C:\WINDOWS\system32>ping 192.168.1.3

Pinging 192.168.1.3 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 192.168.1.3:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Desktop to laptop same output
Salam ELIAS 302 Reputation points

2026-10-13T07:02:47.31+00:00

1 last precision I can ping my internal DNS by its IP but not name
Daphne Huynh (WICLOUD CORPORATION) 1,980 Reputation points Microsoft External Staff Moderator

2026-10-15T06:15:57.07+00:00
Thank you for providing the additional results and for working through all of the troubleshooting steps. The latest tests clarify the situation considerably.

At this point, I would not recommend making any additional route changes. Your latest routing table has the expected directly connected route for the LAN:

192.168.1.0/24 -> On-link -> 192.168.1.3

And the Internet-facing adapter owns the default route through 192.168.0.254. Therefore, traffic between 192.168.1.3 and 192.168.1.6 should not require another static route or the Internet-facing interface.

There are now two separate observations.

1. Your internal DNS server is answering correctly when queried directly

You confirmed:

Resolve-DnsName salam7.salam.net -Type A -Server 192.168.1.13 -DnsOnly

Returns:

192.168.1.3

And the equivalent query for sierac.salam.net returns:

192.168.1.6

That confirms the records on the internal DNS server itself are correct.

Resolve-DnsName -Server specifically queries the DNS server supplied with the command and -DnsOnly restricts resolution to DNS.

There is still a multihomed DNS consideration because Get-DnsClientServerAddress shows that the Internet NIC uses 192.168.0.254, while the LAN NIC uses 192.168.1.13. Microsoft documents incorrect or multiple DNS-server configurations as one area to investigate for DNS client resolution problems.

Also, the latest Get-DnsClient output still shows:

USB10Gbs ... RegisterThisConnectionsAddress = True

If the USB10Gbs interface should never publish its 192.168.0.x address into your internal namespace, I would leave register this connection's addresses in DNS disabled on that adapter.

2. More importantly direct Pv4 connectivity is failing

This is now the deciding test:

Laptop 192.168.1.6 -> ping 192.168.1.3 -> timeout Desktop 192.168.1.3 -> ping 192.168.1.6 -> timeout

Because those tests use IP addresses directly, DNS name resolution is not involved in those failures.

You can reach the internal DNS server by IP, and you previously had a period when the laptop and desktop could ping each other, but after restarting the computers the direct LAN communication stopped again.

That intermittent behavior means there is not enough information in the Q&A thread to reliably determine whether the remaining issue is caused by Windows filtering/firewall state, adapter/driver behavior, an intermediate network device, or another component in this particular network.

For that reason, I do not recommend continuing to add routes, change interface metrics, or make further speculative DNS changes. Doing so may mask the underlying problem.

At this stage, I recommend opening a Microsoft Support case so the issue can be investigated with simultaneous network traces from the laptop and desktop while reproducing:

ping 192.168.1.3 ping 192.168.1.6

I would provide Support with:

ipconfig/all from both computers

route print -4 from both computers

Get-NetIPConfiguration

Get-NetRoute -AddressFamily IPv4

Get-DnsClient

Get-DnsClientServerAddress AddressFamily IPv4

the successful explicit queries to 192.168.1.13

the failed direct IPv4 pings between 192.168.1.3 and 192.168.1.6

the fact that direct communication worked temporarily and stopped again after restart

simultaneous TSS/network traces from both computers during a failed ping

the network topology shown in this thread

Since Microsoft Q&A is a public discussion forum and I cannot inspect the packets, adapter state, firewall/WFP filtering, drivers, or intermediate network devices in your environment, I do not think further configuration changes based only on the information available in the thread would be responsible troubleshooting.

The important progress is that the connected LAN route is now present and your internal DNS server returns the expected 192.168.1.x records when queried directly. The remaining direct-IP failure now needs trace-level investigation by Microsoft Support rather than further route or DNS changes.

Thank you again for all of the detailed testing you have provided.

I hope the information collected in this thread helps Support isolate the remaining issue more quickly.
Salam ELIAS 302 Reputation points

2026-10-15T18:46:54.1933333+00:00

How I can open a Microsoft Support case ? I have never done it