Ordig is a system that enables sysadmins to get WireGuard VPN up and running in their environment quickly. Ordig automates the installation process on both the VPN server and windows clients. Necessity is the mother of invention. Ordig was created to promote social isolation in response to COVID-19. I don’t want my colleagues showing up at work to access local IT resources.
The installation process for ordig is available in the
README.md file on github.
Ordig has several different components that all work together to ensure your windows clients can get access to your internal resources.
Clients need to be able to access the server via web;
tcp/443, and a UDP port of your choosing. The server is responsible for answer client device requests. If the client doesn’t have a configuration, one is generated on the fly. Documentation on the API is available on the server at
The API runs isolated in a docker container. A sqlite3 database provides the storage for the server and client keypairs.
Caddy, caddyserver.com, provides encryption for the front end connectivity to the API as well as a file server that hosts the installation files for your windows clients.
Running outside of the docker containers is a daemon that is responsible for configuring the server’s WireGuard interface. The daemon makes calls to the API and runs command to setup the interface and add clients.
wg.ps1 file runs on the clients. When it executes the following tasks are achieved.
- Generates a random client key and id to uniquely identify the client to the API server
- Download and install WireGuard
- Get the WireGuard client configuration from the API
- Install the WireGuard tunnel service for the client’s config
- Get the DNS configuration from the API
- Download and install Ordig’s WireGuard Watcher Daemon
The client id and unique key ensure that clients cannot get access to other client’s private key.
WARNING: During the installation a client API key was generated and written to
wg.ps1. Anyone with access to this file has access to your network. With great power comes great responsibility. Or as Gandalf said, “Keep it secret. Keep it safe.”
The watcher daemon runs in the background and attempts to query the private internal DNS server. If the internal DNS server is not available, the watcher toggles the VPN up or down. The way this works when a client is off network the watcher will query for the local domain using the internal DNS server. If it doesn’t get a response it turns the VPN on. When the client is on network, the internal DNS server wont be available while the VPN is on. The watcher will toggle the VPN off. Worst case, if your network supports NAT reflection or u-turn, clients will remain connected to the VPN unnecessarily.
When the VPN service is running the watcher daemon adds a DnsClientNrptRule. This rule overrides the clients local DNS for any requests to your internal domain. Queries to resources in your domain will be made against your internal server. When the VPN service is not running the watcher daemon removes all DnsClientNrptRules.
I am able to deploy
wg.ps1 to all my clients using a custom service so long as they have an internet connection. You may have jamf or intune. Perhaps you have remote help desk software and your help desk has access to run a script as admin, you can deploy
wg.ps1 as needed. Once the clients runs
wg.ps1, a split tunnel VPN is up and running all the time.
How did ordig get it’s name you ask? Well I wrote this whole thing in a few days. It was really meant to serve my purposes only but I figured why not spend a few hours making it more generic for anyone to use and share it with the world. I went to my favorite vocabulary site, wordnik.com and looked up the word “tunnel” and I noticed a typo in one of the definitions.
According to urbandictionary.com, this is a real word too.
So if you are in need of such a service, feel free to give ordig a try. And please, if you don’t have a good reason to go out, stay inside!