SoftEther Behind NAT: Direct Traversal or VPN Azure Relay?

Your SoftEther server sits behind a provider router you cannot change, and clients still connect, so you assume a relay is carrying everything. Whether that is true depends on which mechanism did the work: a DNS name, a coordinated UDP path, or an outbound tunnel to a relay. All three can produce a connected client, and they fail under different conditions. Decide which path you are buying before touching users or hubs.

Three mechanisms, three different promises

Dynamic DNS is naming. It keeps a hostname pointed at a changing address so people stop chasing the number, and it does nothing else. Native NAT traversal is coordination: two SoftEther endpoints exchange information and try to open a usable UDP path through the translation devices between them. VPN Azure is a relay: the server dials out to the service, and clients arrive through a hostname on the relay's infrastructure.

The three are complementary rather than versions of one feature. A deployment can use naming while its connection actually depends on traversal or on the relay.

Decide from the client and the network

The choice starts with the client, because traversal exists only in the native SoftEther connection mechanism. OpenVPN, L2TP/IPsec and SSTP listeners on the same server do not inherit it, even though they share a host. Look at what the user will run, then at what the network permits. A corporate network that allows only TCP 443 pushes you toward a relay on that port, while a network that passes the UDP ports traversal needs can attempt a direct path; confirm both against the actual egress policy.

A manually reachable listener is still a legitimate design when an administrator can publish one, but it is a separate project with its own addressing and firewall work.

Confirm which transport the session picked

Connection status is the only honest source for the path in use. Read it on the server, and resolve the hostname the client was given.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList shows which sessions are connected, and SessionGet on one of them reports the connection type, including whether the session arrived through the relay. A record that resolves to relay infrastructure tells you the session passes through a third party, which you can confirm by blocking that route in a test. With a native client, UDP acceleration can move the data path away from the control path, so one observation does not describe the whole session. A stale dynamic DNS name after an address change, and a relay that answers while the backend route is missing, are two failure modes worth testing separately. Record what you measured rather than what the design intended.

Plan for what the chosen path depends on

Every path carries a dependency. A direct traversal can change after a network transition or a new translation device, while a relay session fails when the service or its reachable port fails. Reconnect from a different network and confirm the server identity the client verified, keeping the previously working path in the same test. Then test the private resource behind the VPN, because authorization, hub membership, address assignment and return routes stay your responsibility either way.

Write down the hostname, protocol, feature settings and observed transport. That four-part record is what lets the next person reproduce a working connection.