SoftEther VPN Azure: A Relay Path, Not an Open Port

Your server sits behind a router you cannot configure, so the obvious plan of forwarding a port is unavailable. VPN Azure exists for exactly that situation, and it solves it by reversing the direction of the first connection: the server dials out to a relay, and clients reach the relay instead of the server. Understanding that reversal explains both what the service fixes and every limit you will hit later.

What changes in the path

With a conventional listener, a client opens a TCP connection to a public address that your router forwards to the server. With the relay, the server maintains an outbound connection to the relay infrastructure, and the relay accepts client connections and passes their payload to the waiting server. No inbound port is opened, no static address is required, and the router stays untouched. From the firewall's point of view the server is an ordinary outbound client, which is why restrictive networks permit it.

The relay assigns a name on its own domain to that server, and clients are configured to connect there.

That name belongs to the relay service, which is not a Microsoft Azure VPN Gateway even though both are called Azure something. Treating them as interchangeable produces configuration that cannot work.

Which protocols survive the relay

The relay transports the SoftEther protocol, and the project documents SSTP as a client option, which is useful because Windows ships an SSTP client. It does not become a generic carrier for every listener on the host: an OpenVPN listener, an IPsec responder and an L2TP service each need their own reachable endpoint, and none of them is transported through the relay just because the SoftEther server is connected.

Client profiles therefore point at the relay name rather than at the server address, and an existing profile built for a direct connection will not work unchanged. Check the supported client list for the version you run before designing around a protocol the relay does not carry.

What the relay does not do for you

The relay is a transport. It does not create users, virtual hubs, access policies or routes, and it does not know anything about the private networks behind your server. If remote clients must reach a LAN subnet, the server still needs the bridging or routing configuration, the return path and the firewall policy that make that work. Overlapping address plans at the two ends are also invisible to the relay and remain your problem to solve.

Supported security settings are also yours to choose. The project documentation includes older platform examples, and copying legacy cipher or certificate settings out of an old screenshot is a good way to build a tunnel nobody can audit. Use current guidance for the version you run.

Certificate validation and user authentication remain server responsibilities, and the relay never substitutes for either.

Operate it as a dependency

Availability now includes a third party. When the relay is unreachable, clients cannot connect regardless of how healthy your server is, and the failure looks like a client problem from the outside. Monitor the relay path separately from the server's own health, and keep a documented fallback such as a direct listener on another address for the day it matters.

Latency follows the relay's geography rather than your users' proximity, which is worth measuring before promising interactive performance over it.

Verify the server identity and then a real application path, not just a successful connection banner, and check whether the resource you need is reachable over the address family the relay carries. Record the relay name, the protocol used and the fallback, because those three facts answer most future questions about this link.