VPN killswitch disables SS

Hey,

I do not have any problem with KILL SWITCH feature with SS, i use WindScribe, but i assume you know that if your VPN not signed yes you can have what you call “some problems” → the VPN KILL SWITCH is a feature for computer always ON (from accidentaly disconnect from your ISP) not when you reboot the computer (behalf manually configured), if you want to have SS still connected trust the entire VPN you have i mean the signer and use Wireguard not OPENVPN.

Secondely, kill switch is a protection over public IP leaking on your entire Local computer, is not mean for being used like on/off → to be on/off you have to say to your VPN (connect when the computer start and activate kill switch, With a dynamic IP adress this protection could fall more often).is a protection for Static IP adress (for manufacture)

Thanks for your feedback and it’s interesting to say the least, to see that killswitch results differ.

I have tested everything i could before posting here, so with the app and killswitch enabled starting at bootup to every VPN protocol - in general i use wireguard - as well, but every time SS instantly disconnects.

1 Like

I see,

so that is mean you have a conflit registration process in your drivers from your firewall, there is a problem with the routing service (when you use the killswitch button).

you need to see the settings in your firewall if you have a persistent allowed rule for spyshelter…
"sps_service.exe.

then,
check by (Windows + R) → services.msc (as local admin)

For this go to : sps_service.sys (is it enabled or not (automatic) → you need a local acount)

try to reconnecting it by clicking in the propreties of the service, only when your kill switch is activated

write exactly the error reference & your windows based kernel version (not only 11/10 x64) and send it here, if you want more help ^^.

1 Like

No it was not the firewall, i already tried that in the beginning, i completely disabled firewall while troubleshooting.

But i just discovered that i forgot to trust 1 rule from the vpn provider, and i also trusted a wireguard rule extra and now it’s functioning. I can disable/enable kill switch any time and SS stays connected. I don’t know what did the trick to be honest, but ok… /closed

1 Like

The trick my friend, is that you miss to allow your vpn rerouting all the local drivers you have on services.msc (without a rule), so activating a kill switch button without giving a local permission for this vpn on the firewall; minidriver like sps local connection soft, can’t pass trough it :laughing:.

have a nice day.

1 Like

The solutions had nothing to do with the firewall, everything in regards to the vpn, the protocols and spyshelter is allowed, i didn’t change anything.

When something is blocked on the firewall i get prompted every single time as well, so it’s difficult to miss right…

Yeah but driver is not exe file only, sys file is more deep, a soft firewall can not see deep rules.
:waving_hand:

1 Like

Where did you had to add this rule, I mean in which app? Also, it seems it might have been a conflict between the VPN and SpyShelter, and apparantly this killswitch feature does more than simply blocking the network connection.

Because that was the weird part for me, I don’t see how disabling the network connection could disable SpyShelter’s protection. But perhaps SpyShelter’s self protection should be improved, because I stil believe that a VPN (or any other app) shouldn’t be able to interfere with SpyShelter’s system service.

I did add this rule this extra trusted VPN rule in the SS rules section.

There is no conflict between the VPN and SS, is it exclusively when the kill switch is enabled.
So it has nothing to do with SS.
Also i asked my provider why i had this issue, but posters in this thread with another VPN had not.
Their explanation was, that although the goal is the same, implementations of kill switch differ.

If you have to add a rule in SS, in order to stop the VPN from breaking SS, then I would call it a conflict, or perhaps even a flaw.

Again, no VPN (or other app) should have the ability to stop SS from completely working. Unless it’s another security tool, like for example an AV with behavior blocker. And the weird thing is that I still haven’t heard back from the developers, about if they could reproduce this problem or not.

https://cybernews.com/what-is-vpn/vpn-kill-switch/

Sorry for the delay. We were able to confirm the issue, but if a software is installed on your PC and is already preventing our application from communicating with its Windows driver (not related to the network) then other applications will also have this issue, including antivirus software, and any other software that requires Windows drivers. I’m not sure what we can do if an executable is running on your PC with full privileges and it is putting rules in place to prevent drivers from being communicated with. (Please note that if a malware did something like this then SpyShelter should catch it in allow/deny, or automatically stop it if it’s a known malware, but in the case of this VPN software it is being approved with SpyShelter to run with no rules or limitations.)

Meanwhile we did release an update a couple days ago. Can you install our update and see if the problem continues?

While adding rules for SS to prevent the kill switch from disconnecting worked, but there is a rule “wireguardcsharp” that with every start of the VPN app changes, so this rule has to be allowed every time again.
Not a big problem, but support of my VPN provider informed me that there is a better way.
In the VPN app is a feature “split tunneling” to bypass the VPN, and when i add SS there it’s working normal, without having to add any rules to SS for the VPN.

I assume that every decent VPN provider, or at least most have a split tunneling feature?

1 Like

Whait,
from what i am seeing now o0 ?

1 question : do you confirm that on paranoid Mode there is NO driver white list ?
i am on paranoid Mode, especially when someone do not reveal what VPN he is using, and now you puted it on a white list inside your OWN soft ??

If no, understand that i only trust driver with a root EV certificate authority nothing else !
because they has an inssurance.

paranoid mode :
equal this : Trademark and Brand Usage Policy | Electronic Frontier Foundation
you are not on there trademark (or proove me wrong).

also,
Please i ask it kindly to answer me,
from this : 04/06/2024 - SpyShelter Detailed User Guide – SpyShelter Help :

“If you use Paranoid or Suspicious SpyShelter Protection modes, you may receive Allow or Deny windows. If that’s the case, then every time you Allow or Deny an action, a rule will appear on this rules screen. So, if you make a mistake with an Allow or Deny prompt, you can always go to this screen and fix the issue immediately.”

I ask you kindly the all trademarks you have puted on a whitelist on your private driver.
not the source code, just the trademarks (signers) and hash code.

We donated to EFF but did not renew, so our name is not on their donor page right now. You can click the “Fight for the Future” icon and see us there in that case. You can probably use Waybackmachine to confirm by checking the EFF page.

Yes, since we did not renew we should probably remove it even though we were paying supports before but did not renew yet. Good point.

We have no white lists for anything that is not signed by Microsoft (or our own software) that I am aware of. Is that what you are asking? Sorry for the issue or any confusion.

1 Like

Answer well appreciated — I understand and agree with you. :+1:

As a lifetime user, I would like to address the current driver compatibility and EV certificate requirements in terms of an inssurance, which raise both technical and legal concerns.

You could consider working with the Electronic Frontier Foundation (EFF) and, if necessary, pursuing the matter to the Federal Trade Commission (FTC).

The objective would be to maintain most of your source code private, sharing only a minimal portion, while requesting that Microsoft register and update your driver from version 10 to version 15 — signed by you — without disclosing the core of your application.

As a security application, you should not be subject to contractual requirements that compromise your intellectual property, especially when Microsoft itself does not hold an independent EV certificate.


Why do I say this?

The compatibility driver in use originates from version 10 of Datpol (the former owner) and not from version 15 of the application is not due to any fault of yours,.

the Core Isolation feature (also known as Memory Integrity) is creating significant technical and financial burdens for users seeking privacy. The way Microsoft has implemented and enforced this feature may raise competition law concerns.

The EFF can pursuiing them to the FTC, so you still keep most of your source code private, and only sharing a minimal portion, to pressure Microsoft into registering your driver and updating it from version 10 to version 15 — signed by you, without giving away the core of your application.

no money no engagement, non contract no duty for any inssurance.

IN THE TOP OF IT :
As a security application, you should not be forced into arrangements that compromise your intellectual property most of it when Microsoft does not have an EV certificate too.


Legal info :

This under requirement is not fair:

Prerequisites from the link above:

Abuse : No company should be forced to obtain an EV certificate solely to participate in such security program. Driver tracing and verification by users should be sufficient. Any additional insurance or certification should remain the company’s own responsibility.


Where is the abuse?
Here: Code Signing Agreement | Microsoft Learn — (Terms of Service) → This is not fair.

Relevant excerpt from section 4 — Intellectual Property:

(a) Licenses to Microsoft. Company grants Microsoft, under all Company’s IPR, a worldwide, nonexclusive, royalty-free, fully paid-up right to reproduce and use any code and any installation/technical reference information provided, solely to perform under this Agreement.


PRIVACY AND LOYALTY TO THE JUSTICE COURT CONCERN :

Why is this an issue?

(Microsoft was condemned for abusing intellectual property rights against other manufacturers)

and today : In breach of Article 102 TFEU, prohibiting abuse of a dominant position"

« Any abuse by one or more undertakings of a dominant position within the internal market or in a substantial part of it shall be prohibited as incompatible with the internal market in so far as it may affect trade between Member States. »

Although the Federal Trade Commission (FTC) operates under U.S. jurisdiction, it maintains formal cooperation agreements with the European Commission that allow coordinated action in cases involving both American and European consumers or competition issues.

Cooperation between antitrust from the federal trade commission in usa and the european commision

My conclusion (personal advice):

I would prefer to provide a portion of my source code to a lawyer, free of charge, to legally challenge Microsoft’s rules and secure the ability to sign a Microsoft compatibility driver — without compromising my entire application.

In my view, the “Core Isolation” / “Memory Integrity” feature should not be imposed in its current form, as it remains experimental and risks harming market competition.

Microsoft has no legal right, particularly within the EU, to restrict deep kernel/system-level access for purely commercial purposes without providing users with the ability to encrypt their own searches and input on personal computers — no EV certificate is required for this purpose.

Ps : if you need to put this on another topic, is free of charge :slight_smile:

To clarify, I was just trying to figure out if this is some kind of flaw in SpyShelter itself.

I believe the issue was that this WireGuard VPN was somehow able to block SpyShelter from communicating with the system service (not driver). Normally speaking, SS should be able to protect itself against this, but if I understood correctly, you guys have already fixed this.

Interesting, I wonder why if you enable this feature, all of a sudden WireGuard won’t break SS anymore. You should ask WireGuard what exactly happens when the killswitch is activated, because apparantly it makes a difference whether ‘‘split tunneling’’ is enabled or not.

Isn’t there a way to make SS remember this rule?

To clarify More :
For third-party software like SpyShelter or WireGuard, services are typically linked to a specific driver.
No 3party functional drivers - No services will working smoothly— this is what we call dependencies inside the Windows architecture, often managed through DLL libraries.

All mini-kernel drivers rely on a corresponding service to handle initialization, configuration, and communication with different kinds of user-mode processes (including Trusted Mode).
While not every Windows driver needs a dedicated service (some system-level drivers run without one), for most advanced security or network tools this dependency is essential.

The real problem comes from the TPM 2.0 chip.
In practice, TPM’s main role here is to enforce Microsoft’s security chain — which also protects their business model.

WireGuard is not a Microsoft partner and is not on their WHQL driver signing list.

Example for Wireguard services.exe (containing a dll to search for the specifique driver) :

Service Name: “WireGuardTunnel$SomeTunnelName”
Display Name: “Some Service Name”
Service Type: SERVICE_WIN32_OWN_PROCESS
Start Type: StartAutomatic
Error Control: ErrorNormal
Dependencies: [ “Nsi”, “TcpIp” ]
Sid Type: SERVICE_SID_TYPE_UNRESTRICTED
Executable: “C:\path\to\example\vpnclient.exe /service configfile.conf”

Even if you believe Core Isolation is disabled, Microsoft’s security services remain active at the kernel level when TPM 2.0 is enabled.This is because they are part of the monolithic kernel design, not a detachable mini-driver.

The only way to truly disable these protections is to remove or deactivate the TPM chip — but without it, Windows 11 will no longer boot in a supported configuration, cause windows 11 need also a secure boot operation.

You can bypassing the TPM but it’s illegal even OFF-LINE that is why this is not fair.

In regards to the wireguardcsharp rule, nope. With every start of the app this rule changes thus has to be allowed over and over.
But since split tunneling is THE always working solution, i forgot about wireguardcsharp already.
And since SS is local, i don’t mind using it at all, because all remote traffic is still inside the tunnel.

Writing to wireguard is challenging, because most likely you will never receive a response. I tried when wireguard was new and became hot, but still waiting for a response :slight_smile:

1 Like