SoftEther Virtual Adapter Shows Up but Sends No Traffic

A SoftEther virtual adapter appears in the operating system's network list, reports itself as unplugged, and carries no traffic. That combination is normal for a device with no session attached, and it is also the state you see when the wrong profile is bound to it. The adapter is a device the operating system owns; the session is what gives it life. Work through these four checks in order and stop at the first one that fails.

Separate the Device From the Session

Creating the adapter installs a network device; it does not authenticate to any server. Confirm what the client's connection list says before reading anything into the interface state. A profile that is not connected explains the unplugged status without any further investigation.

The adapter and the physical interface have different jobs. One carries the decrypted traffic the applications see, and the other carries the encrypted outer connection to the server. Confusing the two leads to firewall rules and routes applied to the wrong device. Rules written for the physical interface will not match the tunnel's traffic, and rules written for the tunnel will not affect the outer connection.

Match One Adapter to One Profile

Each adapter should be bound to the connection profile you intend, and the binding should be visible in the client rather than remembered. When several adapters exist, note which profile owns which device before touching either. Reusing an adapter across profiles is how a stale address survives a reconnect.

If the client offers a supported way to recreate the binding, use it instead of editing the operating system's configuration directly. The client writes the adapter's settings on connect, so manual changes tend to disappear or to conflict at the next session.

Read the Effective Settings After Connecting

Once a session is up, read the address, the route and the resolver from the system. The client's status panel describes what it asked for, while the kernel describes what actually happened.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

The address listing shows whether the adapter received anything at all, and an adapter with no address after a successful login points at the profile's configuration rather than at the driver. The route query shows which interface would carry a private destination, which is where a missing route becomes visible. The resolver output shows whether DNS followed the session, since a working link with local DNS still produces a half-broken connection.

A created adapter with no useful settings can coexist with a successful management login elsewhere in the client. The two panels answer different questions, so one is never evidence about the other. When they disagree, the system view is the one the applications experience.

Stop Before Bridging or Deleting

Bridging the virtual adapter to a physical one is a design change rather than a repair. It merges two network boundaries, and it is not a way to fix a missing route. If the deployment needs that arrangement, it needs an authorised design and a test plan.

Deleting an adapter is equally destructive when another service uses it. Identify the owner first, including any other client or virtualisation product on the machine that created an interface with a similar name. A device that reappears after removal is telling you something is recreating it.

Finish by testing the application, not the adapter. A file share or intranet page that loads through the tunnel is the evidence that the device, the session and the route all agree.