Goals

When setting up our network we have a couple of goals. Namely we want a stable network where we can plug in wired devices, as well as connect via Wi-Fi. For now we are happy with creating a single wireless network that all devices connect to, and that is not separated from the wired network. However, it would be possible to create a secondary guest network, separated from our trusted devices.

In addition to the main goal the network should be as easy to maintain as possible. The less configuration that can break the better, and the more resilient it is to changes the better.

Equipment and Terminology

Due to the configurability of the RouterOS firmware (the firmware used by MikroTik devices) this guide will likely be applicable for other devices as well. However, it is only tested with my setup of a wireless access point, and a router/switch combo.

To make it easier to follow along while using other devices this guide will use the name (or Identity in RouterOS terms) cap for the access-point and capMan for the router/switch. The table below gives an overview of the name and role of each device.

To achieve our goal of maintainability we will use a function called CAPsMAN (Controlled Access Point system Manager). This will allow us to centrally manage the access point (and new access-points in the future) from a centralised point. The router will then send updates to all access-points, removing the need to manage them one by one.

Steps

So how to configure a wireless network with MikroTik devices? I’ve broken it down into two steps, first the preparations, and then configuring the Wi-Fi network.

Preparation

The first step to any network configuration is to ensure that each device is reachable and has a recognisable identity (name). I found that it was easiest to factory reset the access-point from the GUI, and choosing the cap preset. This puts the device into a bridge mode, disabling all router functionality and NAT. This gave a good starting point for the rest of the configuration.

With a reset access-point it is time to ensure that each device have a recognisable identity. As described in Equipment and Terminology I will use CAP for the access-point and CAPMAN for the router. It is also important to ensure that the devices has good passwords and are up to date, so I recommend doing so now.

To make it easier to troubleshoot the network I also recommend setting a static DHCP lease for the CAP device. In my case the following IP configuration is used:

Configuring a Wireless Network with MikroTik Devices

With our network in a state were we have a connection between CAPMAN and CAP we can begin to configure the network. The first step is to configure CAP to ask CAPMAN for configurations. This is done by using [admin@CAP] > /interface wireless cap set caps-man-addresses 192.168.88.1. This command sets the address of the manager and ensures that it is the one responsible for the configuration.

Next up we need to configure the wireless network. This is done in multiple steps, as shown below.

[admin@CAPMAN] > /caps-man security add name="wpa2psk" authentication-types=wpa2-psk encryption=aes-ccm
[admin@CAPMAN] > /caps-man security set 0 passphrase=[REDACTED]
[admin@CAPMAN] > /caps-man configuration add name=master-cfg ssid=[My-Wifi-Network] security=wpa2psk country=sweden
[admin@CAPMAN] > /caps-man provisioning add action=create-dynamic-enabled master-configuration=master-cfg
[admin@CAPMAN] > /caps-man configuration set 0 datapath.bridge=bridge
[admin@CAPMAN] > /caps-man manager set enabled yes

The first command will create a new security configuration, specifying that the Wi-Fi shall use wpa2-psk for authentication and AES encryption. After that we set the password. This is the password used to connect to the wireless network when it gets activated. The third step is to set the name of the Wi-Fi (the SSID). Note that we do not want to configure a band here. This will allow the CAP to create a network on 2.4ghz as well as on 5ghz. Otherwise, it would only create the network on the configured band. If we wish to configure the a second Wi-Fi, we would create a second configuration here and add it as a slave configuration in the next step. On line 5 we provision the network to be created. This tells CAPMAN what configuration to push to what device. This means that if you have multiple devices you can set what devices to push it to. For more information use the built-in help or the online documentation for provisioning. The last row is the thing that got me confused. It tells the CAPMAN what bridge (interfaces) the network should be attached to. In my case this is the default bridge, and this allows devices to connected to the Wi-Fi to access the network. The last step is to enable the CAPsMAN configuration on CAPMAN. This turns the configuration on and you should now be able to see your wireless network and connect to it.

Note that if you wish to change something in an existing configuration you need to remove the configured interfaces and then trigger a re provision. This is done by:

[admin@CAPMAN] > /caps-man interface print
# This shows all interfaces, remove all interfaces
[admin@CAPMAN] > /caps-man interface remove 0
[admin@CAPMAN] > /caps-man remote-cap print
[admin@CAPMAN] > /caps-man remote-cap provision 0
# Reprovision all CAPs

There are lots more that can be done with CAPsMAN, but this should be a good starting point. However, I recommend the MikroTik wiki to read up more on the options. There might be other things relevant for your needs.

Summary

Setting up a wireless network with MikroTik infrastructure is quite easy, when you know what steps to take. The steps to take are on the managing device (CAPMAN):

1. Set CAP to use CAPMAN for configuration.
2. Configure the security to use for the Wi-Fi.
3. Configure the password for the network.
4. Create a network configuration to use.
5. Provision the configuration to be pushed to access-points.
6. Configure datapath for the wireless network.
7. Enable the network

And on the CAP:

1. Configure the CAPsMAN manager to use.

This should allow your CAPMAN to dynamically configure any access-points connected to provide network access.

The experience of publishing new posts is about the same as when hosting on Github, you just push an update to the specified branch and then a build is triggered that will be published upon completion. The main difference is that the build process is somewhat slower in Cloudflare than on Github. This means that a build can take about 5 minutes, instead of the previous 1. This is most likely due to the fact that Cloudflare pulls everything and builds locally, instead of using Jekyll remote themes.

When the post is published, there are no major difference for the user, however the statistics for the creator is much deeper. The pure web analytics (provided by JavaScript) could be implemented wherever the site was hosted, but there is more. The web analytics is the most detailed analytics, since it provides what posts were visited, referrers, user agents and more. The Cloudflare proxy analytics on the other hand does not require JavaScript, and can therefore not be blocked. The amount of information provided is not as detailed, but it gives a broader picture of the visitors. This data contains unique visitors and their origin country, but not much more. This could be seen in the web statistics as well, but that tracking is easily blocked.

Even though I have a quite negative stance on tracking, I think that information that is collected in the server anyway can be shown to the content creator without infringing the readers privacy. By being able to track number of readers it’s possible to gain insight in the trends depending on the type of content published. For this blog for example I can from the statistics note that the most interesting content is in the divide between technical security and policies. For example Spotify GDPR Analysis is one of the most read articles on the blog, and it was written before I added analysis, and posts are often read the most directly at launch.

Getting back to the topic at hand, the experience of using Cloudflare, it gives the possibility to handle everything at a single location. This includes managing the domain as an registrar, hosting the application, managing TLS certificates and much more. The only thing I’ve found that is a bit tricky is that I’ve not found a way to register a new domain, only to transfer an existing one. With that said, I’ve been very happy with my switch to Cloudflare, it gives me the tools I need for my blog, and just works.

Migrating from GitHub pages to Cloudflare pages was as easy as configuring what GitHub repo to use in Cloudflare, picking Jekyll and then it just worked. Right after the page was built you see some basic statistics, such as the amount of request grouped by country. Below the first hours of traffic is shown in a map, as presented by Cloudflare.

In addition to providing basic statistics, using Cloudflare gives a lot of additional benefits. This includes the use of their Content Delivery Network, protection from Denial of Service, and easy HTTPS. I have not dug deep into which is best in these regards, but i find it difficult to believe that I have made a significant downgrade.

So in conclusion to gain some basic statistics of the usage of my blog, I’ve migrated it to Cloudflare. The solution will not track any personal data, only basic statistics to gain some insight in how many readers are using/enjoying my blog.

Getting things to work have been quite a fiddle, so lets walk through how I got things up and running.

The first step was to get ruby and jekyll installed on my local machine for testing. After trying with wsl I lost my patience and to my surprise it was easier to install directly in windows. Jekyll has a great guide on how to install ruby, jekyll and all dependencies at https://jekyllrb.com/docs/installation/windows/.

The next step was to create my github repository. To be able to host github pages you have to name the repository <username>.github.io where you replace <username> with your github username. After that I cloned my repository to my local machine and initiated jekyll by running jekyll new . in my repository.

At this point I got a basic blog. By using bundle exec jekyll serve the webpage is built and hosted locally for testing. It works, but now it’s time to pretty the page up a bit. After looking around on different themes for a while I ended up choosing Hamilton, it fits my needs nicely, and i really enjoy the look. Installing it was as easy as following the guide in the documentation, you just have to remember to change the theme in _config.yml, to ensure that you use the new theme. That took far to long to realise, but finally I made it.