Change: DNS

[nhas]

Change: DNS

[NHAS]

Howdy, in review of this I think adding this as a qol improvement is fine, folk who dont want to use it wont!

[paulb-smartit]

I may not always be right, but I'm never wrong :)

Thanks for the consideration.

[NHAS]

On my end I have a deployment script that does more advanced things with split DNS that the DNS= setting wouldnt be able to replicate.

Could you give me a bit more insight into your rollout/deployment process?
I may be able to suggest alternatives

[paulb-smartit]

This is an all new process for us. The current OpenVPN setup works well, but is problematic on Linux with OTP.

I'm looking at making it as seamless as possible for end users. I actually started writing up notes on how we would do this.

Authentication Process

The sysadmin registers a user and is given a registration key.

$ sudo ./wag registration -add -username dominic
token,username
RegistrationToken1234567890,dominic

The user is given their registration code as part of a URL.

https://otp.domain.tld/register_device?key=5e56461cfa3abcb14569e8581e2836944b02394d1974e66ff7b07e6e906865fd

When the users visit this URL a wg0.conf file is downloaded that contains their details to logon with. This file should be installed in /etc/wireguard or imported into the mobile WireGuard app.

A development I would like to see here is it both downloads the config, and presents a QR code that can be scanned by the mobile app.

Once the registration is successful the token is consumed and is no longer valid to download the config again.

When the user brings up the WireGuard tunnel using the app or on Linux using sudo wg-quick wg0. The basic connection is made.

To gain further access the user must visit http://otp which will present them with a QR code and a secure key to use to register with an OTP app like FreeOTP or Google Authenticator.

Using FreeOTP to generate the OTP the user then types, or pastes, the OTP into the web page and WAG authenticates them, granting the user a 12-hour session. The user can then visit any of the systems they have been given access to, until they have to reauthenticate in 12 hours time.

[NHAS]

Ha, funny enough thats almost exactly our use case as well. So, what I do is I get the machine UUID (Mac), then use the optional -token parameter to make it into a registration token.

Then with JAMF I push out a script which effectively queries the endpoint with the various machines UUIDs, installs wireguard and away you go.

[NHAS]

E.g

sudo ./wag registration -add -username dominic -token $UUID_HERE

Then

curl https://your.wag.public.endpoint/register_device?key=$UUID_HERE

That way you can do it with centralized management.

[paulb-smartit]

I will probably automate the deployment using ansible for wireguard and even the wg0.conf, it's jsut the DNS part that I would "fix" with ansible too. I just thought by adding a dns into the config.json it could push it out too, and also add the firewall rule to allow it.

[NHAS]

My suggestion would be to append the DNS setting you want with your deployment process into the wg0.conf that is generated.
Reason being, is I'd prefer people to be able to define their own ACLs/Routes so it's very explicit as to what is allowed.

Adding a DNS option to wag becomes challenging from two standpoints.
First, what happens if you update the DNS server? I have the ability to regenerate and supply the routes to the client through the /routes/ api.
Second, its a question of what I, or we, want wag to be I want it to be a simple solution that governs network access.

I may change my mind later on once I've had a bit more of a think about it. But I think for the moment this is outside (but only slightly) what I want wag to be.

[paulb-smartit]

My suggestion would be to append the DNS setting you want with your deployment process into the wg0.conf that is generated. Reason being, is I'd prefer people to be able to define their own ACLs/Routes so it's very explicit as to what is allowed.

Adding a DNS option to wag becomes challenging from two standpoints. First, what happens if you update the DNS server? I have the ability to regenerate and supply the routes to the client through the /routes/ api. Second, its a question of what I, or we, want wag to be I want it to be a simple solution that governs network access.

The DNS part sorts out the resolv.conf changes when the user connects/disconnects. Without it, I'm guessing you're using something that handles calls for internal addresses and external?

I may change my mind later on once I've had a bit more of a think about it. But I think for the moment this is outside (but only slightly) what I want wag to be.

Of course, and it's not out of the realms of people like me easily manipulating how things are done with other tools, The core part that makes me smile is the ACL's and firewall. Much of the actual admin and user interaction parts can be customised and done other ways.

[NHAS]

Yep, for us we're effectively using split dns and an internal domain that directs all traffic to the internal (over wireguard) dns servers.

[NHAS]

Sweet, this is now here: https://github.com/NHAS/wag/releases/tag/v1.0.5

Or in the main branch, enjoy!