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.
This article is about building a secure travel wifi router using a RaspberryPi and the Wireguard VPN protocol. It is a long and technical article describes how I stopped worrying about untrusted and insecure wifis in hotel rooms and conference venues.
The Problem I travel a lot and therefore often rely on wifi provided in aircrafts, hotels or conference venues. Unfortunately, the state of security of those uplinks is worrying, connections are often buggy and rarely encrypted.
Some time ago I was porting a piece of IPv6-only network software from Linux to OpenBSD. This post is to explain the caveats of using struct sockaddr_in6 and its member sin6_scope_id. It turns out, OpenBSD does not play too well with sin6_scope_id and uses a rather odd method of populating the scope ID to user space.
Linux and sin6_scope Let’s start with Linux and have a look at the documentation first.
I wrote a small python script used in a demonstration aimed at raising wifi security awareness amongst campus visitors. The script displays SSIDs sent out from the phones or other devices of people passing by. I found this script to be an useful eye catcher in awareness campaigns.
It leverages the scapy framework and is pretty easy to setup. A wireless card in monitor mode is basically all you need to get started.
Here is my latest OpenBSD endeavor: Running multiple instances of the same daemon using different configuration files for each instance.
For the sixfw IPv6 firewall project we need multiple instances of the unbound resolver. We use address family translation (NAT64) for traffic passing some interfaces. For true v6-only networks and for the router itself, we don’t (or just can not) use address family translation. Therefore we need one resolver that does expose 64:ff9b::/96-based DNS RRs for some interfaces, and a second one that refrains from using its DNS64 superpowers at all.