Your VPN works normally over Wi-Fi.

Then you connect a USB-C dock or Ethernet adapter to use a wired network.

Ethernet itself works. Websites open normally before the VPN starts.

But after the network handoff, one of these problems appears:

• the VPN disconnects;
• the VPN reconnects but internet access disappears;
• public websites work but corporate resources fail;
• internal company names stop resolving;
• the VPN says Connected, but traffic is using the wrong interface.

This is different from a broken RJ45 port.

If USB-C Ethernet works before the VPN connects, investigate routes, DNS, and adapter priority before blaming the Ethernet hardware.

The most useful approach is to compare the network state before and after switching from Wi-Fi to wired Ethernet.

Create a Before/After Network Record

Do not change DNS servers or interface metrics yet.

Start in the configuration that works:

Wi-Fi → VPN → Internet / Corporate Network

Open Command Prompt and run:

ipconfig /all

Then:

route print

In PowerShell, also run:

Get-NetIPInterface

Record only the important differences:

This gives you a known-good state before troubleshooting the failed handoff.

Difference 1: Ethernet Became the Preferred Interface

Connect the USB-C Ethernet adapter.

Leave the VPN disconnected temporarily.

Confirm:

Ethernet → Internet works

Then check:

Get-NetIPInterface

Windows may now prefer Ethernet over Wi-Fi.

That is not automatically a problem.

Microsoft explains in its network interface metric guidance that interface metrics help determine adapter preference, and the effective metric used for route selection can combine the route metric with the interface metric.

You may see something like:

Ethernet    InterfaceMetric  15
Wi-Fi      InterfaceMetric  45
VPN        InterfaceMetric  25

A lower metric often means higher preference when otherwise equivalent routes compete.

The important question is not:

“Why did Windows prefer Ethernet?”

It is:

“Did the change in preferred interface break the VPN's expected route or DNS behavior?”

Difference 2: The VPN Was Established on the Old Network

Suppose you originally connected like this:

Wi-Fi → VPN

Then you plugged in Ethernet without disconnecting the VPN.

The underlying physical network has changed.

Your laptop may now have:

• a different source IP;
• a different gateway;
• a different interface metric;
• a different network profile.

Some VPN clients handle this transition cleanly.

Others need to rebuild the tunnel.

Use this sequence:

1. Disconnect the VPN

2. Connect USB-C Ethernet

3. Confirm normal internet access

4. Temporarily turn Wi-Fi off

5. Reconnect the VPN

If the VPN now works

The Ethernet hardware is probably functioning correctly.

The problem was triggered by the live:

Wi-Fi → Ethernet handoff

rather than by RJ45 connectivity itself.

For regular use, try establishing the preferred network connection before starting the VPN.

Difference 3: The Default Route Changed

With Ethernet connected but VPN disconnected, run:

route print

Then connect the VPN and run it again.

Look at the routes that appeared or changed.

A VPN may operate as:

Full Tunnel

Most network traffic uses the VPN.

Split Tunnel

Only specific company networks use the VPN, while ordinary internet traffic continues through Ethernet.

The exact behavior depends on the VPN profile.

Suppose your company resource is:

10.20.10.50

and your VPN should install a route covering:

10.20.0.0/16

If that route disappears after the Wi-Fi-to-Ethernet transition, the VPN may show:

Connected

while the internal resource remains unreachable.

That means the problem has already moved beyond the USB Ethernet hardware.

Read the Route Before You Change It

Windows prefers the most specific matching route first. When matching routes have the same prefix length, metrics help determine which one wins.

So avoid blindly assigning manual interface metrics just because:

VPN works on Wi-Fi but not Ethernet.

First determine:

• which route exists;
• which adapter owns it;
• what metric Windows is using;
• whether the expected VPN route appears at all.

On an IT-managed computer, avoid manually creating corporate routes unless your network administrator specifically instructs you to.

VPN clients often manage those routes intentionally.

Difference 4: Ethernet Works Until the VPN Connects

This is an especially useful symptom.

Before VPN

Ethernet → Internet ✓

After VPN

Ethernet → VPN Connected → Internet ✕

This strongly suggests that the physical Ethernet connection itself is functioning.

Now determine whether the VPN is:

• taking over the default route;
• installing the wrong route;
• failing to forward traffic;
• changing DNS behavior.

If your organization uses a full-tunnel VPN, losing general internet access can occur when the tunnel becomes the preferred route but cannot carry traffic correctly.

For a split-tunnel VPN, check whether only corporate destinations fail or whether all browsing stops.

These are different results.

Difference 5: IP Works but Corporate Names Do Not

Now separate routing from DNS.

Suppose:

Corporate IP address → reachable

but:

fileserver.company.example → not reachable

That points more strongly toward name resolution.

Run:

ipconfig /all

Check the DNS servers associated with:

• Ethernet;
• VPN adapter;
• Wi-Fi, if still active.

Windows VPN profiles can provide their own DNS servers and Name Resolution Policy Table rules. Microsoft's VPN name-resolution documentation explains that NRPT rules are checked first, while interface preference and metrics can influence DNS behavior when no matching rule applies.

That is why changing from Wi-Fi to Ethernet can affect DNS even when the VPN itself still shows Connected.

Use the Right DNS Test

For ordinary DNS, you can test a name with:

Resolve-DnsName microsoft.com

Then test an internal FQDN:

Resolve-DnsName fileserver.company.example

If your organization relies on Windows VPN NRPT rules, Resolve-DnsName is more appropriate than relying only on nslookup.

Microsoft notes that applications using their own DNS implementation can bypass the Windows DNS API and NRPT behavior; its VPNv2 documentation specifically identifies nslookup as an example.

Public DNS Works, Internal DNS Fails

Check:

VPN DNS server

NRPT rules

DNS suffix

VPN route to the DNS server

Both Fail Only After VPN Starts

Check whether the VPN's DNS or full-tunnel route is reachable at all.

Flush DNS Only After the Network Path Makes Sense

You can clear stale DNS cache with:

ipconfig /flushdns

But do not treat that as the primary fix.

If Windows is using the wrong interface or the VPN DNS server cannot be reached, flushing cached names will not repair the underlying problem.

Use this order:

Verify Routes

→ Verify VPN DNS

→ Confirm Interface Preference

→ Flush DNS

→ Retest

Use Ethernet-Only Mode as a Diagnostic

One of the fastest isolation tests is:

Ethernet ON

Wi-Fi OFF

VPN reconnect

Now test:

Public Internet

Corporate IP

Corporate DNS

Everything Works

The issue is likely related to the two physical interfaces being active simultaneously or to the handoff between them.

You may not need to leave Wi-Fi disabled permanently.

You have simply proved:

Ethernet + VPN works when Wi-Fi is removed from the decision.

That is useful evidence before touching interface metrics.

Establish a Simple Ethernet Baseline

If you normally use a feature-heavy docking station with:

HDMI + storage + charging + audio + Ethernet

and want to determine whether the VPN problem is specifically related to networking, simplifying the physical setup can be useful.

A USB-C to Gigabit Ethernet adapter supporting up to 1000Mbps provides a cleaner reference network path without adding display, storage, or charging functions.

The LENTION CB-CU604E is designed as a dedicated USB-C-to-RJ45 connection, with up to 1000Mbps Ethernet and plug-and-play operation.

That makes it useful for a test such as:

Laptop → USB-C Ethernet Adapter → Router

Then:

Confirm ordinary Ethernet

→ Connect VPN

→ Compare routes

→ Check DNS

The important boundary is:

A stable Gigabit Ethernet adapter provides the physical network interface; Windows and the VPN client still control routes, metrics, DNS, and tunnel policy.

So changing to another Ethernet adapter cannot repair a badly configured VPN route or corporate DNS policy.

Its value here is creating a simpler baseline network path.

When Manual Adapter Priority Is Worth Testing

Only consider manual interface metrics after you can show that Windows is selecting an undesired interface.

You can inspect current interfaces with:

Get-NetIPInterface

Windows also allows interface metrics to be configured using Set-NetIPInterface. Microsoft documents this as the modern method for changing network-interface preference.

For example:

Set-NetIPInterface -InterfaceAlias "Ethernet" -AutomaticMetric Disabled -InterfaceMetric 15

But do not copy that value blindly.

Your company may intentionally configure:

• VPN metrics;
• split tunneling;
• Always On VPN;
• MDM policies;
• traffic filters.

For managed systems, capture:

Get-NetIPInterface

and:

route print

and give those results to IT before making permanent changes.

Know When This Is Actually an Ethernet Problem

Continue with this article when:

Ethernet works before the VPN starts.

If instead you see:

• no Ethernet adapter;
• no IP address;
• RJ45 link failure;
• 100Mbps instead of expected Gigabit;
• ordinary internet fails even without VPN;
• adapter repeatedly disconnects;

use the USB-C hub Ethernet not working or slow troubleshooting guide instead.

That guide handles the physical network layer.

This article handles:

working Ethernet + broken VPN behavior.

Corporate Network? Check Authentication Before VPN

There is another boundary in managed offices.

If the USB Ethernet adapter is detected but the corporate wired network never authorizes it, VPN troubleshooting is premature.

If the office uses port-based authentication, use the 802.1X Ethernet authentication troubleshooting guide first.

If the network works with one Ethernet interface but rejects the USB adapter because its network identity changed, check whether the issue is the Ethernet MAC address presented by the USB-C adapter.

The correct sequence is:

Ethernet Link

→ Network Authorization

→ IP Connectivity

→ VPN

→ Routes

→ DNS

The Handoff Diff Sheet

When the problem happens, record this rather than simply reporting:

“VPN breaks through my dock.”

This immediately tells you which layer changed.

Quick Answers

Why does my VPN disconnect when I switch from Wi-Fi to USB-C Ethernet?

Switching networks can change the laptop's source IP, preferred interface, gateway, and route table. Some VPN clients need to rebuild the tunnel after that handoff.

Why does Ethernet work until I connect the VPN?

The physical Ethernet connection may be healthy while the VPN changes routes, DNS servers, or traffic policy.

Why does the VPN say Connected but corporate sites fail?

Check whether the required corporate routes exist and whether internal names resolve through the VPN's intended DNS path.

Can Wi-Fi and Ethernet both being active cause VPN problems?

They can expose interface-priority or routing problems. Temporarily disable Wi-Fi and reconnect the VPN over Ethernet as a diagnostic.

Should I manually change the Ethernet interface metric?

Only after confirming that Windows is selecting the wrong interface. On managed computers, check with IT before changing metrics permanently.

Will another Ethernet adapter fix my VPN?

Not if the real cause is routing, DNS, split tunneling, or VPN policy. A different adapter is useful mainly for proving whether the physical wired path is stable.

Final Takeaway

When a VPN disconnects or loses internet after switching to USB-C Ethernet, compare what changed during the handoff:

Physical Adapter

→ IP Address

→ Interface Metric

→ Default Route

→ VPN Route

→ DNS

The most important rule is:

If USB-C Ethernet works normally before the VPN connects, troubleshoot above the physical RJ45 layer first.

A clean diagnostic sequence is:

Connect Ethernet

→ Confirm Internet

→ Temporarily Disable Wi-Fi

→ Reconnect VPN

→ Compare Routes

→ Check VPN DNS

→ Adjust Interface Metrics Only If Necessary

This turns:

“My dock breaks the VPN.”

into a much more precise question:

Did the network handoff change the route, DNS path, or preferred adapter that the VPN expected?