SoftEther VPN Developer Edition: A Multi-Protocol VPN Server Built in C

What SoftEther VPN solves, and who it is for

Most VPN servers pick one protocol and stop there. OpenVPN speaks OpenVPN. WireGuard speaks WireGuard. SoftEther VPN's stated design goal is the opposite: a single server program that terminates SSL-VPN over HTTPS, WireGuard, OpenVPN, IPsec, L2TP, MS-SSTP, L2TPv3 and EtherIP on the same host. The README lists that as the first advantage, and the comparison table confirms which of those protocols appear in which edition.

The audience is narrower than the feature list suggests. This is the developer edition master repository. The README says plainly that the repository contains experimental code, that pull requests are welcome, and that the stable edition at SoftEtherVPN/SoftEtherVPN_Stable is the one a non-developer can use reliably. So the people who should be reading this page are the ones building from source, testing a protocol the stable edition lacks, or embedding the server into their own image. Administrators who just want a running VPN should start elsewhere and come back only if they hit a gap.

The second audience is the constrained-network case. The README advertises SSL-VPN tunnelling on HTTPS specifically to pass through NATs and firewalls, plus VPN over ICMP and VPN over DNS. Those features exist because the project originated in an environment where a client could not assume any given port was reachable. If your users sit behind a network that permits only outbound 443, that constraint is the whole reason to look here.

One daemon, several protocol front ends, and a shared core

The repository builds four binaries from one codebase: vpnserver, vpnclient, vpnbridge and vpncmd. The Dockerfile shows the build producing all of them alongside hamcore.se2 and two shared libraries, libcedar.so and libmayaqua.so. The server, client and bridge are separate entry points into the same engine rather than separate products.

That layout explains the protocol coverage. The protocol handlers sit in front of a common tunnel and session layer, so adding WireGuard support in the developer edition did not require a second daemon. It also explains why the stable and developer editions diverge by feature rather than by architecture: the comparison table lists differences such as AEAD mode in OpenVPN, ECDSA certificate import, IPv6 route management and TLS server verification, all marked as available in the developer edition and partial or absent in stable. Same codebase, different points on the release curve.

Three deployment shapes fall out of this. vpnserver is the endpoint. vpnbridge connects two networks at layer 2, which the README calls Ethernet-bridging. vpnclient is the client-side daemon for machines that should not run the GUI. The Dockerfile builds each as a distinct image target, so a bridge host does not carry the server binary and vice versa.

Configuration state lives in directories the build sets explicitly. The Dockerfile passes SE_PIDDIR, SE_LOGDIR and SE_DBDIR as CMake flags, pointing at /run/softether, /var/log/softether and /var/lib/softether. Those three paths are what the compose file mounts. If you change them at build time, the volume mounts in your compose file have to change with them, and nothing in the repository will warn you if they do not.

Installing SoftEther VPN Server with Docker Compose

The repository ships a Dockerfile and a docker-compose.yaml, and ContainerREADME.md at the top level is the intended starting point for container users. The compose file defines a single service named softether using the image softethervpn/vpnserver:latest, with NET_ADMIN added to the container capabilities and restart set to always. That capability is not optional: the server manipulates network interfaces, so a container without it will not bring tunnels up.

Only two ports are uncommented in the shipped file, 443 and 992. Both are labelled for management and HTTPS tunnelling. Everything else, including DNS tunnelling on 53, OpenVPN on 1194, the alternate HTTPS port 5555 and the IPsec/L2TP set on 500, 4500 and 1701, is commented out. You enable a protocol by uncommenting its line:

services:
  softether:
    image: softethervpn/vpnserver:latest
    cap_add:
      - NET_ADMIN
    ports:
      - 443:443
      - 992:992
      - 1194:1194/udp
      - 500:500/udp
      - 4500:4500/udp

State persists through two bind mounts that the file already declares, ./softether_data to /var/lib/softether and ./softether_log to /var/log/softether. The file also carries a commented adminip.txt mount at /var/lib/softether/adminip.txt, marked read-only, which is the mechanism for restricting who may administer the server. Leave it commented and the admin interface is reachable by whatever can reach port 443.

Bring the stack up with the standard compose command from the repository root:

docker compose up -d

For a first real use, the practical path is not the GUI. The image copies vpncmd into /usr/local/bin, and the container's default command is vpnserver execsvc, so the server is already running when the container starts. Attach to it and use vpncmd to set an administrator password and create a user, rather than exposing the HTML5 console before any credential exists. The README notes that the server also exposes an HTML5 Ajax-based web administration console and a JSON-RPC API suite, which is the interface most people will want once credentials are in place.

Where SoftEther VPN is the wrong choice

The clearest limitation is stated by the project itself. This is the developer edition, and the README directs non-developer users to the stable edition instead. That is not marketing hedging; the comparison table backs it up by listing features that differ between the two, including certificate authentication, IPv6 handling, TLS server verification and dual-stack name resolution, several of which are marked partial in stable and full here, and others the reverse.

IKEv2 is marked unsupported in both editions. If your client fleet is built around native IKEv2 profiles, this project does not cover you, and no amount of protocol breadth elsewhere changes that. The table is explicit about it.

Compatibility cuts the other way too. The developer edition does not run on Windows XP or earlier and is not compatible with SoftEther VPN 1.0, both of which the stable edition supports. If you have legacy endpoints, the newer code is a regression for you.

The README also links ANTIVIRUS.md as a top-level document. A project that maintains a dedicated file about antivirus false positives is telling you something about how its binaries are sometimes received. Plan for that during packaging and endpoint rollout rather than discovering it in a support queue.

Finally, the protocol breadth is a surface-area argument as much as a convenience argument. Running SSL-VPN, WireGuard, OpenVPN, IPsec, L2TP, MS-SSTP, L2TPv3 and EtherIP behind one daemon means one process to patch, but also one process whose exposure set is the union of eight protocols. Turning off what you do not use is a configuration decision, and the compose file's commented port lines make that decision visible rather than automatic.

SoftEther VPN compared with a single-protocol server

The honest alternative is not another multi-protocol suite. It is running WireGuard on its own, or OpenVPN on its own, and accepting that you will operate more than one daemon.

The difference in approach is structural. A single-protocol server has one code path, one port, and one set of failure modes. WireGuard's model in particular assumes a fixed UDP port and a small configuration surface. SoftEther VPN's model assumes the opposite: that the network in front of you is hostile to fixed ports, which is why the README advertises SSL-VPN over HTTPS, VPN over ICMP and VPN over DNS, and why it bundles dynamic DNS and NAT traversal so that no static or fixed IP address is required. Those two designs are answering different questions.

If your clients are on managed networks where you control the firewall, the single-protocol approach is simpler and the multi-protocol server buys you little. If your clients are on networks you do not control, the ability to fall back to HTTPS on 443 is the feature that matters, and no single-protocol server offers that fallback by design.

The same logic applies inside this project's own family. SoftEther VPN Server is the multi-protocol endpoint; the stable edition is the same endpoint with a narrower feature set and a longer compatibility tail. Choosing between them is a question of whether you need WireGuard, full certificate authentication or IPv6 route management, all of which the comparison table attributes to the developer edition. If you do not, the stable edition is the lower-risk build of the same architecture.

Licence, maintenance and the cost of tracking this branch

SoftEther VPN is licensed under Apache-2.0, and the repository contains the full LICENSE file plus a document titled Declaration_Switch_License_from_GPL_to_Apache.pdf, which records the project's move from GPL to Apache. Apache-2.0 is a permissive licence with an explicit patent grant, which is generally the reason a project like this is embedded into commercial images rather than merely run. That is a factual description of the licence text, not legal advice; if you are redistributing a modified build, read the LICENSE and the NOTICE obligations yourself.

One redistribution detail is easy to miss. The README states that the project received an Icons8 licence covering the icons in resources/, and that you are not allowed to redistribute those icons outside of this repository. The source licence and the asset licence are not the same thing, and a downstream image that ships those icons is outside the permission the README describes.

On maintenance: the last push to this repository was on 2026-09-13, which is recent. The most recent release listed is 5.2.5188 from 2025-07-18, preceded by 5.02.5187 and 5.02.5186 in September 2024. That is a gap of roughly ten months between the two most recent releases, so the branch sees commits between releases even when tagged builds are sparse. If your deployment depends on tagged artifacts rather than master, budget for that cadence.

The upgrade cost is the developer-edition trade itself. Tracking master means tracking a branch the README describes as containing experimental code, and the feature comparison against the stable edition is a moving target rather than a fixed contract. Every upgrade should be preceded by a check of that table for the specific protocols and features you rely on.

Editorial conclusion

Adopt SoftEther VPN when you need one daemon to terminate several VPN protocols at once, when clients are behind NAT and you cannot open arbitrary ports, or when you want Ethernet-level bridging rather than plain IP routing. Do not adopt this repository if you need a non-developer deployment: the README states the stable edition at SoftEtherVPN_Stable is the one non-developer users can rely on, and the comparison table shows the developer edition drops Windows XP and SoftEther 1.0 compatibility and adds WireGuard, IKEv2 is marked unsupported in both. Before deploying, verify three things: that your chosen protocol appears in the comparison table for the edition you actually built, that the volumes you mount line up with SE_DBDIR, SE_LOGDIR and SE_PIDDIR, and that you have read ANTIVIRUS.md, since the README links it as a known issue rather than a footnote.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. SoftEtherVPN/SoftEtherVPN on GitHub