Organizations are switching to WireGuard®. Why?
- It’s very fast
- It’s very efficient
- It’s baked into the Linux kernel
This makes WireGuard® ideal as a networking layer for distributed systems like IoT and Kubernetes, as well as for remote access. However, there are still many challenges involved in setting up a WireGuard® virtual network at scale. Specifically, configuration management and access controls. Netmaker automates WireGuard® configuration, decreasing the level of complexity necessary to manage WireGuard® across many devices.
In v0.12.0, Netmaker introduced Access Control Lists, which allow operators to manage fine-grained ACLs. Put simply, this creates an easy system for controlling which machine can talk to which. In this article, we give a quick demonstration of managing WireGuard® access controls with Netmaker.
Setup
Our setup consists of a Netmaker server and 6 machines running in AWS: Four in us-east-1 and two in eu-central-1. All machines run Linux. All machines have been added to the Netmaker network acl-net-1.
By default, Netmaker creates a “full mesh” P2P network, meaning every machine can reach every other machine. We can see this in the Graph visualization:
Now, let’s restrict this network with ACLs.
ACLs
In the ACL page on Netmaker’s UI, you get a full list of all P2P connections in the network. You can disable any pair of connections by clicking on it.
As you can see, by default, all connections are enabled. Lets make it so the nodes in Germany cannot talk to the nodes in Virginia.
You can click on an individual node to restrict its connections:
You can also change rules from the main screen:
Once you click “SUBMIT CHANGES,” the nodes will be notified immediately and update their local settings.
This also propagates to the Graph view, which shows the update:
When we check the local peer settings, we see it has been updated to show only the peers for which it has access.
Our network is now successfully segmented, but what about the inverse scenario? What if, by default, no machine should have access to any other machine. In this scenario, you want to manually approve every machine’s access.
Default Deny
We can achieve this by creating a network with a “default deny” policy. Any machine that enters the network will have no peers, and no connections. Let’s create a network with this setting enabled:
Note that “Default Access Control” is switched off. This is what changes the default policy to “deny.”
After creating, we join all of our nodes to the new network.
As you can see via the Graph, none are connected:
On each node locally, it will show no peers are present. We can now begin to build up our network.
This time, we enable all the small machines to talk to each other:
Again, this populates to the UI after submitting:
*Important Note on Default Deny
We also switched off UDP Hole Punching in this scenario. Why? UDP Hole Punching relies on the client having a connection to the server node. If this is disabled, connections will break. Alternatively, we could have switched on UDP Hole Punching, and then ensure we manually enable every node’s connection to the server in the ACL page.
Conclusion
This concludes our quick demonstration of implementing ACLs on WireGuard networks with Netmaker. There are many use cases this applies to, from IoT, to Kubernetes, to Remote Access. Stay tuned for additional tutorials where we look at some specific use cases.
Disclaimer: WireGuard is a registered trademark of Jason A. Donenfeld.
