My Design Jam Experiences

Yesterday, I joined the Munich Design Jam for the second time. Last time, hosted at IXDS Munich, I created an Alexa skill prototype for social and educational cooking with a team of strangers. This time the topic was Microsoft Hololens-assisted furniture assembly for millennials. Organized and lead by Rachel and Johannes and their team, it was once again an enriching and fun experience. The event was kindly hosted by Vectorform’s Munich office.

A Design What?

What the heck is a Design Jam you ask? Here is the official definition from the organizer’s website:

A Design Jam is a one-day event that brings together Designers, Developers and Entrepreneurs, to solve a problem and build a prototype in just 10 hours (or so). Each Jam’s theme will be announced on the morning of, for maximum excitement.

Unlike last time, I knew most of my team. It consisted of my brother Thies, my fiance Tina, and Yuliya who joined our team as a second designer.

Eight Minutes, Eight Ideas

A Design Jam is run on a tight schedule. Every task has a time limit, and those limits are challenging! After all, you have about 8 to 10 hours to create a presentation and a prototype, involving a technology you may have never heard of or touched before.

Our first task was to come up with eight different ideas regarding the problem of furniture assembly in eight minutes. That sounds harder than it is, once you started the flow, new ideas won’t stop coming to mind. Maybe that’s the reason for the time limit. πŸ€”

Once we had our ideas noted down, we explained them to each other in our group and voted on them using sticker dots.

Everyone then had to pick one idea and spend a couple of minutes elaborating it. Most of us picked an idea that wasn’t our own but from another team member and that we have found interesting.

We presented our elaborated ideas to each other and totally blew the two-minute time limit we had for that. 😜

Categorizing Ideas

Then we had to place our ideas on a value and effort matrix, which invoked some discussion and took as slightly longer than expected. The most interesting quarter of the matrix is the target quarter. That are ideas which are expected to provide the customer with high value and require little effort to develop or implement. We voted once again, this time on all ideas from within the target quarter. To make things more challenging, we landed a tie between an idea involving QR codes and an augmented reality disassembly guide. We could not break the tie, so we went with combining these two ideas into one, which gladly worked out. πŸ‘

Earn Your Pizza

The host ordered plenty of pizzas for everyone and just as they were delivered we finished with our tagline. It reads QRreconstruct - sustainable furniture that follows you! You can read from the tagline that we are (a) not native English speakers and (b) were starving. I wish we had found a better tagline but on the other hand, we were really exhausted by the work we had done so far. Funny, how easy it is to compromise when the smell of delicious pizza is in the air! πŸ˜‚


After lunch and networking, we started prototyping and creating our presentation. Johannes used the afternoon to go from team to team and give everyone the chance to experience the Hololens themselves. He and the other organizers also checked our progress regularly and advised us when needed.

Our team decided to shoot a video explaining the app and a typical use case. Although scratching on the upper end of the definition of millennial, I was chosen to star in our awesome video. 😬

Here is the video:

Presentation And Party!

In the late afternoon, it was time for all teams to wrap it up and deliver their presentations. This is usually the best part of a Design Jam and this time was no exception. The creativity level in the room was cranked up to 11 πŸ˜‰and we had some good fun with the entertaining and convincing presentations that were delivered.

We spent the rest of the evening having some beer and interesting conversations about this and that and of course technology.

I recommend attending a Design Jam to everyone who likes designing and prototyping!

How to configure WireGuard on OpenWrt/LEDE using LuCi

A while ago, I simplified the way WireGuard interfaces are configured with in-tunnel IP addresses.

So here is a new step-by-step guide on how to configure a WireGuard tunnel on OpenWrt/LEDE. WireGuard is a cryptokey routing protocol, or, as many refer to it a VPN.


For this guide I assume you run the latest snapshot of, let’s say LEDE. 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 one or more Addresses and 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.

Click Save and Apply once you are satisfied.

Now you should have a WireGuard tunnel interface

I also created a monitoring module. It is called luci-app-wireguard and should be available in all major repositories. Why not give it a shot while you are at it?

You can also 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.


The former approach required an static interface on top of the WireGuard tunnel interface. Unfortunately, this was introduced to address concerns that were raised in the merging discussion on luci-proto-wireguard. I never was a big fan, but saw it as a necessary evil to get the change merged in time. #politics It’s all history now πŸ™ƒ

Update (July 2018)

I receive quite a few emails on the topics of OpenWrt and WireGuard every week. Unfortunately, I do not have the time to answer all of them individually. So I kindly ask you to direct questions regarding WireGuard and OpenWrt/LEDE to the OpenWrt Forums or to the WireGuard Mailing List. There the questions will be exposed to a wider audience and may additionally help other people facing the same challenges. Thank you!

Project sixfw - Lessons Learned

tl;dr: I am closing the SIXFW project. It hurts, but having learned from it makes it easier.

A bit over a year ago, at the Chaos Communication Congress 2015, I was part of the team responsible for the NAT64 part of the congress network. We usually used a commercial appliance to do the IPv6-to-IPv4 translation. Running super-expensive carrier equipment is at the heart of our operations, but whenever possible we like to deploy open-source software or equipment developed by the hacker community. There was no NAT64 appliance that fell under this definition at that time and I think as of today there still is none. At least none that I am aware of. So I decided to do something about that and initiated the SIXFW project with a clear objective:

An easy-to-use, non-bloated firewall/NAT64 appliance that thinks IPv6 first.

In retrospect, this was a hell of a objective.

I gave a lightning talk about my idea and the day after a couple of interested people gathered providing opinions, tips and ideas. Up to this day, however, I never released anything that comes close to my goal. Here is how and why I failed:

Lesson 1: Scope!

The attentive reader may have seen the contradiction in our objective already. A contradiction I did not see back then, though. When we aim for ease of use, we can hardly address the professional market for NAT64 appliances. Commercial NAT64 appliances come with a lot of configuration options, there is a knob or switch for everything. They pose a frustratingly high barrier for network engineers who are new to NAT64 networking. Lowering that barrier was one of my goals. This meant less features, less options to chose from and less ability to adapt to the very network the appliance should serve. Eventually, turning the professional appliance into a consumer router with NAT64 capabilities. I wanted to develop an appliance for a complex technology (which has it’s nifty caveats) that could be used by the average grandmother. I did not scope my project properly. I did not have a clear definition of the target audience.

Lesson 2: Do your research!

I quickly settled for OpenBSD as the underlying operating system. Partly because I liked the stability of it, and partly because I believed that there are already enough Linux- or FreeBSD-based firewall distributions around. What I did not do was proper research. I should have asked myself which operating system really is the best for the problem, taking into account the ecosystem, packaging infrastructure, release schedules and security patching processes. If I had approached this topic more open-minded, I may or may not have chosen another operating system.

Lesson 3: Do not re-invent the wheel!

It sounds so simple, but it is actually hard. When you aim for a very lean software product and begin your research on existing components to include, you see bloat everywhere you look. For sure I wanted to avoid bloat! But was every feature of a component I would not use already bloat? Harmless code that never gets executed but has to be shipped or patched out scratches on the image of perfect. Nevertheless, writing everything from scratch just to have the best-fitting solution comes with a lot of work and introduces new problems. For example, I did write a web interface and a restful API for configuring the firewall. To be precise, I wrote a piece of software that would read a definition of an API and produce static code for a server (python) and a client (HTML5, CSS, JavaScript) that implement this very API. Meta-programming if you will. Beautiful, but totally unnecessary. As so often: Done is better than perfect!

Stepping back

After a year of development, I began to realize that I would not have my prototype ready for the 2016 Chaos Communication Congress. Damn! Instead of panicking, I did something that often helps me to clear my head in messed-up situations: Stepping back and start dissecting the ashes.

It took me a couple of hours to clear my head and evaluate the code, the objective and the possibilities. Then I decided to try something different: Why not take an existing firewall distribution and turn it into a NAT64 appliance. Just for the fun of it, just to see what it would look like, just to learn from how else I could approach the problem. So I took a look at OpenWrt/LEDE and started adding Jool to make it run NAT64 in kernel mode (there were user space tools for that already, but they are not performing well). I then extended the existing Unbound DNS package to support DNS64 configuration options. Now there were NAT64 and DNS64 capabilities in a well-established distribution. And for the most common scenarios, they were even configurable via web interface! It was a great pleasure to see such success in such a short time after spending too much time and resources on developing a similar solution from scratch.

This happened close to the end of the year and it was about time to think about the event’s NAT64 network. Again, stepping back and trying another approach helped me clear my mind. I ended up writing a small Go program that would generate all necessary configuration files to turn an freshly installed OpenBSD into a NAT64 appliance. No web interface, to fancy bling-bling, just plain and reliable configuration files. It worked very well!

What’s next?

So, where will I go from here?

  • I will continue to contribute to OpenWrt/LEDE. Especially in the areas of IPv6-only networking and NAT64. There is still a lot to be done in this field. I’d rather contribute to a successful project that actually helps people than swimming in my own soup alone. I see more potential for learning for all of us when IPv6-only networking is accessible to a broad range of interested people.
  • Since NAT64 works surprisingly well and reliable on OpenBSD, I will keep my little Go program and generate updated configuration files every time I need to deploy an appliance-like server for NAT64. But no further energy will be invested into making it a fancy, shiny pet. It works and that is good enough in this case.
  • I will be shutting down the SIXFW project, including it’s website, Twitter and GitHub accounts.

Thank your reading this and certainly thanks to all of you who supported the SIXFW project in one way or the other. I learned a lot and hope sharing my lessons learned helps someone else some day, too! What a ride!

Bonus Material

Although I will not proceed with SIXFW but shutdown the project, I wanted to think about how I could have done it better. So I imagined myself being back in December 2015 and starting the project. This time by writing a project outline to explain the project, divide the work and conquer it.

The Problem

The Internet suffers a severe sickness called IPv4 address exhaustion (see appendix for details). It took the Internet community a while to develop and apply the cure in form of a new Internet Protocol called IPv6. Today, the patient is stabilizing and IPv6 deployment rates have been growing more than linear. One problems remains, though: These two protocols are not designed to be interoperable. Once a network goes IPv6-only, connectivity to the old Internet is gone. All nodes in that network (end users, servers, everything) will be excluded from information that is not accessible via IPv6. The negative side effect of the emergency cure we just applied is the patient slowly loosing vision on one eye. As a believer in the free flow of information, I think this is a problem that needs to be solved.

The Solution

The scope of this project is to build a NAT64/DNS64 translating network appliance. This involves choosing a suitable hardware platform alongside a mature, well-performing operating system. The software will use the platform efficiently. However, it will not be bound to a specific product or vendor and will provide compatibility with a large range of products from different price categories. For example, SIXFW is expected to run on a low-cost computer as well as on a high-performance enterprise server. The software will be designed using multiple components. A user interface will provide statistics and system health data as well as allow configuration of operational parameters. Using a dedicated control daemon, system tasks will be separated from the user interface to provide an additional layer of security. Proper access management and sane defaults (read: preconfigured for most applications) will ensure that initial functionality will provided with minimal administrative overhead.

Target Audience

The SIXFW appliance will be useful for anyone who uses or maintains a state-of-the-art network connected to the Internet. Although the vast majority of end users will not know that their information flow to the old Internet is being translated, they will benefit from the existence of an open-source ready-to-use NAT64/DNS64 appliance. More tech-savvy users may want to use SIXFW in their home networks alongside existing customer premise equipment (CPE, e.g. a Fritz!Box). Organizations may chose to prefer open-source solutions for their connectivity for security or budgetary reasons. As SIXFW matures, it may operate side by side with enterprise appliances at internet service provider level, transparently serving hundreds or thousands of people. SIXFW significantly lowers the barriers to access information that would otherwise be invisible. Everyone who regularly accesses wired or wireless networks and varying locations with different uplink capabilities is the target audience. If you use the Internet, you are part of this project’s target audience. However, I will do my best to avoid you noticing it, so that you can access the information you want without disturbance.

Project Risks

Reaching mile stone EVALHW depends on the availability of different hardware platforms. Supply shortage may lead to delays. This risk has been mitigated by an upfront investment in hardware. I have at least three platforms to evaluate, independent from market availability.

Mile stone ALPDEV consists the major development part of the project. Due to its highly integrated nature, single components are expected to be develop in parallel using an incremental approach. Further division of this mile stone into smaller tasks is intentionally avoided. This poses a risk on the overall project, as time estimates may be significantly off. Furthermore, unforeseen complexity issues or unexpected inter- dependencies could add additional workload.

The event, which will provide the environment for testing taking place to reach mile stone ALPTST, is in an early planing stage. I follow the progress of the planning committee closely to get early notice of relevant changes. For example, the event could be canceled due to funding issues or external threats like harsh weather conditions. I plan to mitigate this risk by choosing another test environment, e.g. an indoor conference, if necessary.

Milestone EVALHW

  • Evaluate hardware platforms (3-4) and operating systems (2-3) for reference implementation
  • Install different OS on different platforms
  • Document experiences issues and caveats
  • Document opportunities
  • Evaluate how fit-for-purpose each platform is
  • Investigate possible OS and security update workflows
  • Assess NAT64/DNS64 installation routines


  • Hardware platform evaluation result matrix
  • Operating system evaluation result matrix

Milestone REFDEFV

Develop reference implementation

  • Install chosen operating system on chosen platform (clean install)
  • Manually install and configure NAT64/DNS64 services
  • Manually install and configure router services
  • Develop sane default firewall rules (as a starting point for further improvements later)
  • Run client connectivity tests with major mobile and workstation operating systems


  • Reference implementation source code
  • Full documentation on how reference implementation was build

Milestone REFTST

SIXFW reference implementation field test

  • Deploy and integrate reference implementation at 33C3 hacker conference network (I am member of the network operating center and will be responsible for transition technologies in the NAT64 part of the network)
  • Document and fix bugs that show up during real-life deployment (~2 days)
  • Document bugs, issues and collect anonymized usage data for later analysis during operational phase of the conference (~4 days)


  • Short, summarizing field test report
  • Updated source code of reference implementation

Milestone ALPDEV

Develop alpha release

  • Design solution architecture
  • Proposed architecture contains: control daemon, user interface, statistics daemon, update functionality, user interface security and access management


  • Source code of alpha release

Milestone ALPTST

SIXFW alpha release field test

  • Deploy and integrate reference implementation at the next outdoor hacker event network (I am member of the network operating center and will be responsible for transition technologies in the NAT64 part of the network)
  • Document and fix bugs that show up during real-life deployment (~2 days)
  • Document bugs, issues and collect anonymized usage data for later analysis during operational phase of the event (~4 days)


  • Short, summarizing field test report
  • Updated source code of alpha release

Milestone INFSTR

Build supporting infrastructure

  • Develop tools for release management
  • Develop tools for building and signing of pre-configured ready-to-go releases
  • Create initial documentation
  • Design and update the website to reflect the project (current page content is misleading and not in line with the project goals)


  • Tools
  • Documentation
  • Updated website