How to configure a WireGuard tunnel on OpenWrt using LuCi

[Update April 2017: I noticed people are still building configurations based on this outdated blog post. The way wireguard addresses interfaces in OpenWrt/LEDE has changed. Please consult a more recent blog post on the topic!]

A couple of months ago I worked on a concept for a sophisticated, IPv6-only overlay network spanning multiple sites and various devices. It is part of a a long-term project, which means assessing not only current, but also future protocols was suitable. The WireGuard cryptokey routing protocol was one of the candidates. The more I work with this still experimental protocol, the more I am convinced that this will become one of the major VPN protocols. It is lean and clean, easy to configure and exceptionally reliable. Furthermore, it seems to be very secure. But as a word of warning, I am less of a cryptography auditor and more of a programmer and network engineer.

I do believe in WireGuard and had the luck to participate in the project by contributing documentation and regularly testing the snapshots. It is a small, agile (BS Bingo!) and responsive group. The development speed is amazing and the head developer probably never sleeps 😮

Today I’d like to show you how to configure a WireGuard tunnel using OpenWrt/LEDE and luci-proto-wireguard. I developed luci-proto-wireguard during the past weeks as a side project. With the help from beta testers and experienced OpenWrt folks, the code matured and now awaits merging into the official repositories.

For this howto I assume you run the latest snapshot of, let’s say OpenWrt. I will also assume that you have a basic understanding of WireGuard.

First step is to create the WireGuard interface. Go to the Interfaces page and create a new interface. Select WireGuard VPN in the dropdown menu. If this option does not show up, then you are missing luci-proto-wireguard 💩. Head over to Software and install it.

Think of good name for the interface, in this article we will proceed using foo 😬 Next thing you will see is the interface configuration page. I tried to make it as self-explanatory as possible by including helpful hints below the options. Most important configuration data are the Private Key of the interface and the Public Key of at least one peer. Also, don’t forget to add the network or address of the other end of the tunnel to Allowed IPs. Otherwise the tunnel won’t work as expected.

If you like to add some post-quantum resistance, you can do so in the advanced tab.

In the firewall tab, you can create a new zone or assign the interface to an existing zone. I recommend doing this after the device is set up and working.

Click Save and Apply once you are satisfied.

Now you should have a WireGuard tunnel interface, but it has not been assigned an IP address yet. I wanted to allow a wide range of setups and enable everyone to do even the weirdest things with their routers. So I removed the direct addressing feature that I was implemented in an earlier version. Luckily, you can create a static configuration on top of foo by creating a new device and selecting Static address as protocol.

It is important to select foo as the underlying interface, either by finding it in the interface list, or, if it does not (yet) show up there, by typing @foo into the custom interface field.

Voilà! We now have the standard static addressing page. Configure according to your VPN concept and hit Save and Apply to proceed.

You should now see both interfaces in your interface list. I recommend putting them into the same firewall zone for easier administration. You can tell that I moved them into the same zone from the color of the interfaces. Interfaces foo and bar share the same firewall zone color.

I’d like to add some monitoring, but that isn’t ready yet. In the meantime, you can check on your WireGuard interface(s) using wg on the command line.

If you find any bugs, please report them. Thanks for reading and happy cryptokey routing everyone!

Hint On some devices it may be necessary to restart the device after after installing luci-proto-wireguard, so that the netifd daemon correctly loads the helper script that comes with wireguard-tools. Thanks Stefan for pointing this out!

Additional antennas for Turris Omnia

In an earlier post I mentioned the rather disappointing wifi signal strength of my Turris Omnia. Other users reported similar issues, so it looks like I am not the only one suffering. To put things into perspective: My router’s signal strength is about 75% compared to the previous COTS device (100%). Clearly, we are talking about #FirstWorldProblems here. 😢

It is still unclear why some devices remain under expectations.

  • Is it a hardware issue? Or software?
  • Is it the driver blob?
  • Is there a problem with the connectors?
  • Are the antennas broken?
  • Could it be an issue with the two pre-antenna filters?
  • Why are both bands affected?

I wanted to rule out antenna and connector issues to help the community find the problem. The idea is to replace the filters, stock antennas and stock HF cables. So I went on a shopping spree and bought five dual-band antennas with 5dBi gain and corresponding HF pigtails.

Two filters are connected upstream of the antennas on the left and right (red circles). The third antenna in the middle is directly connected to the 2.4GHz wifi card.

I replaced the filters and the gray stock HF cables. Each antenna is now directly connected to one of the wifi cards via pigtail. I also replaced the stock antennas, to refute the broken antennas theory.

No special tools were needed, there were already five SMA holes in the case.

And now the most important piece of information: Did it work? Unfortunately, no, I have not seen a significant improvement of signal strength, regardless which band I looked at.

At least we now know that a hardware issue including the antennas or filters is less likely. The quest continues… 📶❓

Turris Omnia: My first impression

A long time ago I backed the CZ.NIC Turris Omnia open-source router on Indigogo. Like all good campaigns, it was delayed and overfunded (by 800%). A couple of weeks ago I received my perk for supporting the campaign: The Turris Omnia.

And what a great piece of router hardware that is! I love it! I almost regret that I went for the cheaper option with 1GB RAM instead of 2GB. However, I have not hit the RAM limit yet. But you never know, right? 🙃

The Omnia comes in a clean package and with a plug of your choice and three dual-band antennas. I chose Type A, but of course the device is also avalaible with EU plug if needed.

The front is equiped with programmable, dimmable RGB LEDs, including two extra LEDs that can be used for almost anything.

On the back we find five gigabit Ethernet ports for the LAN side. Another gigabig Ethernet port is available for the WAN side. One can also plug in an SFP and go fiber. However, only one of the WAN ports may be used at a time.

Let’s peek inside the Turris Omnia: Uncluttered and with room for expansion. Awesome!

The filters that merge the signals from the two wifi cards were a bit loose. That was easy to fix, here is a video that shows how:

Furthermore, I think that the wifi signal strength is a bit disappointing, it is beyond my expectations. Nevertheless, this is a great piece of hardware worth every dollar.