What a SoftEther Virtual Hub Actually Connects

SoftEther's Virtual Hub is a membership boundary inside one server, not a location. Sessions that join the hub can reach what the hub is attached to, and sessions on another hub cannot, even when both authenticate against the same server. That is why a successful login can still put a client on the wrong network. Reading the hub as a virtual switch clarifies what it does and what it leaves to bridging, routing and cascade configuration.

A Hub Is a Membership Boundary

One server can host several hubs, each with its own users, sessions and policy. Authentication establishes who the session is, while the hub decides which virtual network that session joins. Two hubs on one host therefore behave like two separate switches that happen to share hardware. Nothing about a successful login implies the session landed where you intended.

Use the operator's documented hub name rather than a name remembered from a screenshot. A client that joins the wrong hub reaches a different network with a valid credential, which is a configuration finding rather than a security breach. Keep the hub name and its purpose in the connection profile notes.

Administration is scoped the same way. A hub administrator manages that hub, while the server administrator manages the process, the listeners and every hub on the host.

Attachments Decide What Lies Beyond

A hub on its own connects sessions to each other. Reaching anything else depends on how the hub is attached: a local bridge to a physical interface, a virtual router, or a cascade to another server. Each attachment carries its own forwarding rules and its own failure modes. Assuming a hub provides internet access is the most common mistake made about the product.

SecureNAT is the built-in option, implemented with a virtual router and a virtual DHCP service inside the server. It is convenient for a lab and awkward for anything needing predictable addressing or policy. A local bridge puts the hub onto a real segment, which inherits that segment's switching, DHCP and broadcast behaviour.

A cascade links two servers so sessions on one hub can appear on the other. That is a hub-to-hub relationship, so both ends need compatible policy and a working path between them.

Read Sessions and Policy Separately

Session, MAC address and IP address views describe what the virtual network currently looks like. They are observations, not permissions. A session visible in the list is not thereby entitled to every service the hub can reach, and the reverse also holds.

Compare the session list with the policy that should apply to it. A device with an address outside the intended range usually means DHCP from somewhere else or a manually configured client. A MAC address that moves between sessions means a migrated device or two devices sharing an identity. Both are worth a look, and neither is proven by the table alone.

On the server, vpncmd reports the same picture from the host's point of view. Compare that output with the client's own view whenever the two disagree.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Treat hub administration as its own role rather than a client permission. Delegating one hub should not hand over the listeners or the process that hosts every other hub.

Check the Client After Joining

From the client side, an established session proves only that authentication and the hub name were accepted. Confirm the address, the route and the name resolution separately, because each can fail after the hub accepted the session.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

The address listing shows whether the adapter received a lease from the intended source. The route query shows which interface would carry a private destination, and the resolver query shows whether DNS followed the session. A hub that forwards packets while DNS still points at the local network produces the classic half-working connection.

Test the application rather than the link. An intranet page that loads is stronger evidence than an adapter with a plausible address.