WireSock Secure Connect 3.x: what’s behind the release notes

For us, this is not just another update, but a transition to a new architectural base. It provides clearer separation of components, better isolation, and new capabilities that both regular users and administrators have long awaited.

At the same time, the product itself has become noticeably more complex. There are more settings, as well as usage scenarios, and this change is not so much due to good circumstances as it is influenced by external factors, generously supported by funding and the rapid pace of work from the well-known government bodies. In this article, I want to go slightly beyond the release notes and discuss things that may not be immediately obvious, but best explain why WireSock Secure Connect 3.x was even needed.

New Architecture

One of the most frequently criticized shortcomings of the official WireGuard client is the difficulty of activating connections for users without elevated privileges. The reason is quite simple: in Windows, operations related to creating and configuring network interfaces are tied to administrative rights or delegated powers to manage network configuration, which are usually associated with the built-in group of Network Configuration Operators.

In WireSock, this problem was partially circumvented through the so-called "transparent" mode. In this scenario, packets are intercepted by the network driver, encrypted and decrypted using IP address translation, thus eliminating the need to bring up and configure a separate virtual adapter.

In practice, this significantly simplified the use of VPNs in environments where users do not have local administrative rights and where the mere request for elevated privileges becomes a problem.

However, the solution still remained partial. In virtual adapter mode, WireSock, including version 2.x, like the official WireGuard client, encountered the same architectural peculiarity of Windows: elevated privileges were required for such a scenario.

In this situation, a logical step was to divide the application into two parts: a privileged service part that performs system operations, and a client part that is responsible for its configuration and tunnel management.

In my opinion, this scheme has noticeably increased convenience. The VPN can now be brought up even before the user logs into the system; the UI does not have to be kept running constantly, it can not only be minimized to the tray but also completely closed, and launched only when necessary. At the same time, a CLI tool has appeared that can work with background services and opens up normal usage scenarios from the command line.

Of course, there was criticism. The logic from users was clear: I closed the VPN, but some services are still living their own lives. This led to a natural suggestion to add buttons for starting and stopping services in the UI. But this would bring us back to the very point we were trying to leave: the user interface would again have to be tied to privileged operations and, in essence, would need to be run with administrator rights again.

Yes, this model may seem unfamiliar. But this separation gives the main advantages of the new architecture. It removes unnecessary dependency of user scenarios on elevated privileges and allows WireSock to work not as a monolithic application with a window and network logic mixed together, but as a more mature system with separately functioning interfaces, services, and VPN connections. This is the direction we are trying to develop WireSock, primarily as a mature enterprise solution.

KillSwitch / Network Lock

This feature has been requested from us for a long time and quite insistently. It already existed in some form before, but only in the virtual adapter mode, where its implementation was close to that used in the original WireGuard client and relies on the routing table. Such an approach cannot be called the most reliable, and for transparent mode, it is utterly inadequate.

It should be noted that the request for such a feature was at times quite emotional. One user from the USA even promised at one point to stop using WireSock if KillSwitch didn't appear. Considering that this was about a free product, the pressure was not the most "binding," but for some reason, it stuck in memory.

In WireSock Secure Connect 3.x, the KillSwitch is implemented at the network NDIS filter level, meaning it involves a more stringent and lower-level blocking mechanism. Because of this, the KillSwitch can be configured to block all traffic upon losing the VPN connection, crashing the background service, or even when switching between profiles.

At first glance, the feature seems quite simple, but in practice, it is one of the most important elements for scenarios where traffic leakage is unacceptable. This can be remote work, access to internal corporate resources, using VPNs in networks with strict restrictions, or simply a situation where the user does not want applications to go online bypassing the tunnel, even for a short time.

It is worth mentioning one not-so-obvious feature that may arise when using the "strict" KillSwitch, that is, in a mode where blocking is not lifted automatically when the tunnel is disconnected. In such a configuration, there may be difficulties with reconnecting if the server endpoint is specified by domain name rather than IP address. The problem here is simple: with active blocking, the client may simply be unable to resolve this name through DNS and, accordingly, will not be able to re-establish the connection.

We have tried to smooth out this scenario as much as possible. In WireSock, IP addresses are cached, and when switching between profiles, domain names are resolved through the existing tunnel whenever possible. But this particular feature is still worth keeping in mind, especially if strict blocking policy is used and configurations rely on DNS names.

Global Split Tunneling: one setting instead of a zoo of exceptions

This, again, is one of those features that we have been asked for a long time. Before version 3.x, split tunneling settings had to be specified separately for each profile, and at some point, this began to turn into a small but very tedious source of chaos.

In practice, many users' set of exceptions has hardly changed from profile to profile. The servers, countries, and connection parameters changed, but the list of applications, addresses, or routes that needed to be sent bypassing the tunnel or, conversely, forced through it, often remained the same. As a result, the same settings had to be duplicated manually, keeping track of them so they wouldn't diverge between profiles, and remembering each time where exactly something was still not fixed.

This is why in version 3.x, split tunneling can be configured globally, once for the entire application, and then these rules can be applied to all profiles at once.

In a dry list of changes, this may seem like a minor convenience, although in reality, the significance of this feature is much greater: less duplication, fewer discrepancies between profiles, and more predictable client behavior.

Support for AmneziaWG 2.0

This is another feature that we have been asked for a long time, for well-known reasons. As I have noted several times in previous publications, WireSock Secure Connect is based on the implementation of the WireGuard protocol from Cloudflare, specifically BoringTun. It is worth noting that it significantly outperforms the forks of wireguard-go, one of which is actually the basis for the original Amnezia client for Windows.

We have added the processing of H1–H4 packet tag ranges directly into our fork of BoringTun. The S1–S4 parameters are already processed in the WireSock code itself. Going forward, we want to develop this mechanism towards more plausible obfuscation and eventually replace randomly generated inserts with an emulation of real network protocols.

However, it is worth mentioning some differences. To be honest, the I1–I5 parameters have always seemed overly complicated to me for the average user. The idea of capturing a binary dump of a packet in Wireshark and then manually inserting it into the config looks interesting, but it is more of an engineering exercise than a setup that can be considered truly user-friendly.

Therefore, at WireSock, we chose a different approach and added our own parameters for generating simulation packets. Instead of the set I1–I5, we use Id, Ip, and Ib: domain, protocol, and browser profile. Currently, profiles for masquerading as QUIC and DNS are supported, and we plan to expand this list in the future. In practice, this scheme turns out to be clearer and more useful because it allows working not with abstract numbers but with a more meaningful configuration model.

CLI: two different tools

It is worth mentioning separately the changes related to the command-line tools. The minimalist console client, which existed since the very first version, has been moved to a separate installer SDK, and along with the new architecture, another CLI has appeared for managing background services.

The format of the separate SDK better reflects the real role of this client. Starting from the second version, it was needed not so much as an alternative to the main UI but as a backend for tools like TunnlTo or SplitWire-Turkey, as well as the basis for minimalist deployment scenarios and integration into third-party solutions.

The demand for such a minimalist client was quite significant. At one point, even Microsoft came to us with statistics on its crashes, where the count was in the tens of millions of events. This sounded quite alarming, but the bug itself turned out to be rather harmless: after finishing its work, the client tried to write a message to the log. Fixing this was not difficult, and the story turned out to be rather amusing, but it clearly shows that this tool was indeed used a lot and in many different scenarios.

The new CLI, which appeared in version 3.x, addresses a different task. While the minimalist console client was primarily aimed at headless scenarios and integration, the new tool has become part of the service architecture of WireSock Secure Connect and is designed for managing background services from the command line.

In practice, this means that the main actions related to connecting, disconnecting, and managing profiles can now be performed without a UI and without any workarounds. For automation, scripting, and simply more minimalist ways of working, this has turned out to be a natural development of the new service model.

Where to Find All This

For obvious reasons, for some users, the question of "where to download" in recent years has become just as practical as the question of "what's new."

For installation via winget, the main client is published as NTKERNEL.WireSockVPNClient, and the minimalist console client as NTKERNEL.WireSockVPNClientCLI. On the WireSock website, downloads for Secure Connect and SDK are also available separately.

However, the website itself is not perfect either. wiresock.net, as one might guess, is unstable or not accessible at all for some providers in Russia. Therefore, we try to duplicate the latest versions in the official Telegram group as well. However, even with Telegram, the situation is also ambiguous in our challenging times. The irony, in the end, is that in order to download the VPN, sometimes another VPN is needed first.

In Conclusion

If we try to condense everything said into one thought, WireSock Secure Connect 3.x has become more complex not for the sake of complexity, but because the surrounding world has not become simpler. Behind the dry release notes lies not just a list of new features, but an attempt to make the tool more resilient to scenarios that a few years ago seemed rare or even exotic.

As always, we welcome feedback, comments, and bug reports. All of this helps move the product in the right direction.

Wishing everyone well.