Prevent users from disconnecting AOVPN user tunnel

MousefluffI'm going to rewrite this one as well, due to some sort of issue with posting replies about service configurations on a site designed solely for sharing technical information with other people ( someone either edited it, or it disappeared due to a glitch. ) Windows itself isn't a client. Windows is an operating system ( monolithic kernel. ) You can switch at the drop of a hat from workstation to server using the MMC snap-in ( services.msc, ) enabling the Server service, disabling the Workstation service, and then going into System Properties and changing this -> Advanced -> Performance -> Advanced -> Processor Scheduling: Background Services

Knowing that this is modular enough that you can script it in the same way as Windows Server, you can partition each adapter on the network, and isolate / sandbox each program, enough that you could create your own "kill-switch" functionality just using scripts ( to block all traffic in the event that you lose the connection. Of course my VPN has this, as well as split-tunneling, but it's a post-paid product. ) Most commercial-quality VPN routers have WAN failover for HSPA / 3G, 4G / LTE, 5G, etc, and WiFi support. The main difference between these and the software firewall implementation on a PC, is that you can't block the Network Time Service like you can on a PC, or tunnel it over the VPN. You'll never be able to connect, and you won't know why, but the obvious reason is the time stamp doesn't match. If you pull out the battery as well, with the "kill-switch" engaged, you can't reconnect, and you have to reinstall it, or disable the VPN to be able to use it ( this is why they bypass the VPN / Firewall sometimes to allow NTP, or they synchronize the clock on startup. It's really problematic with mobile devices, but nothing else. ) With VyOS, all you need is an adapter to create your own access point, or you could even use a HTPC board with two Ethernet MACs ( it's very flexible, and you can even run it in a container using WSL / docker, on top of the operating system image. ) You could also make your own fixed-login process by forking OpenVPN and hard-coding the login, so nobody could disconnect, along with a custom network stack and service configuration. It's still vastly inferior to a VPN router, but understanding the drawbacks is an important part of learning how it works. If you don't understand this, then you won't be able to learn from your mistakes, or you won't understand the limitations of what you've learned. This is how I think about things, not just what I would tell someone else:

"the VPN clients are external on random connections, home broadband, mobile hotspot, coffee shop wifi etc"