Getting IPv6 in Barcelona

This blog post was published in coordination with the one on ungleich’s blog about bringing IPv6 to Barcelona.

Who are we and why do we care about IPv6?

We, Camilion Consulting & Development, are a small company based in Barcelona, and we provide outsourcing and consulting services in the Architecture, Engineering and Construction (AEC) world, while also developing software to help engineers worldwide work better and faster, so that they free themselves from fighting the tools and keep doing wonderful things.

So, we are not an Internet Service Provider (ISP) and we don’t have a huge infrastructure (it keeps growing though).

Basically, we don’t make the internet, we are what you might call advanced users of the Internet.

Now, if we are just advanced users, why do we care about IPv6?

Well, while not being a huge company or an ISP, we do have the will and knowledge to self-host any services that are critical for our operations.

Why a company would want to do that is a question better answered on a future post, but the quintessence is that politics have an effect on the world and what is a good/free/cheap service today, can either not be available to us or be a huge liability in the future.

And, as it turns out, being a small company means that we cannot afford in time and effort changing providers for Operation-critical services every couple years and we cannot assume a sudden or huge downtime due to things out of our control like services shutting down, changing terms and conditions, or plain political instability.

Running our own services is much easier and cheaper with IPv6, not only is IPv6 Only Hosting cheaper, it is something we can do ourselves, on our own premises, without being an ISP.

What is the state of IPv6 around Iberia?

According to Google’s IPv6 report, Spain has an IPv6 penetration of 2.16% (as of January 23rd 2019).

Taking into account that Google has pretty much a search monopoly in Spain, this means that their data, when it comes to IPv6 penetration, reflects quite well the state of the market.

As you can see, it is a pretty bad situation.

It’s not that it’s not possible to get IPv6 at all, but the main ISPs in the state do not offer that service and in fact, based on our experience, many of their technicians and most of their support (even for companies) don’t really know what IPv6 is.

There are smaller, local ISPs like Iguana or Parlem that offer IPv6 connectivity, and some big ISPs are starting to test waters but, like with many bottom-to-top changes, it will likely take some time. And, in case you wonder, we cannot currently use those.

We need IPv6, we need it now. How to get that?

We have a very good relationship with the people at ungleich and IPv6 is one of their strengths, and a focus point of their on-going crowdfunding, we decided to both help them out and finally solve our IPv6 needs once and for all by contracting their VPN for a /48 block.

Since they needed to allocate the block and setup the routing, which coincidentally meant that they had to setup new servers, Nico, ungleich‘s CEO, proposed we gave WireGuard a go.

This has a bunch of advantages server-side, which we already geeked out about privately, and will be published on a follow-up post by him. A preview can already be found here.

On the client side this meant:

  • No fiddling with certificates and Certificate Authority files
  • A one-time 10 minute setup
  • Not having to consider IPv4 subnets in the tunnel and our routing

Pre-requisites

You will need a UNIX-based system, for multiple reasons our Operating System (OS) of choice is Devuan, but the instructions are just as applicable to any Debian-derived system.

We have also been told that this setup works on FreeBSD/OpenBSD, which are also wonderful OS’s, but were not used this time.

Installing WireGuard

Turns out, installing WireGuard is quite easy if you are running a recent-enough system. For us, this meant Beowulf, Devuan‘s current testing. In Debian that means Buster.

WireGuard is currently only available on unstable, which means that we had to add that to the repositories.

$ echo "deb http://deb.devuan.org/merged unstable main" > /etc/apt/sources.list.d/devuan_unstable.list
$ apt update

This, however, risks upgrading everything to unstable, which is not really what we want.

Desired state is: as long as the packages we need are not available on our target release, we want to use those. But as soon as they are, those in our release have priority.

Luckily, this is quite easy with apt preferences:

$ tee /etc/apt/preferences.d/unstable.pref << EOF

Explanation: Only install packages from unstable if explicitly asked for or the package is pinned
Package: *
Pin: release a=unstable
Pin-Priority: -1
EOF

$ tee /etc/apt/preferences.d/wireguard.pref << EOF

Explanation: Install wireguard from unstable as long as it's not present in testing
Package: wireguard wireguard-dkms wireguard-tools
Pin: release a=unstable
Pin-Priority: 50
EOF

# Replace $arch with your architecture
$ apt install linux-headers-$arch
$ apt install wireguard
# WireGuard runs as a kernel module, compile and install it
$ dkms autoinstall wireguard

Setting up the interface

WireGuard‘s man pages are wonderful, so check man wg and man wg-quick to complement this.

There is a very neat command called wg-quick, which takes care of creating and setting up the interface for you. In order for it to work though, you’ll have to create a /etc/wireguard/INTERFACE.conf file like this:

$ tee /etc/wireguard/wg-ungleich.test.conf << EOF
[Interface]
PrivateKey = $(wg genkey)
Address    = 2a0a:e5c1:XXXX::1/48
# PostUp   = /etc/wireguard/wg-ungleich-up.sh
# PreDown  = /etc/wireguard/wg-ungleich-down.sh

[Peer]
PublicKey = hi60lGP+xEUQ+kVnqA7PlJAO1SVqTS1W36g0LhFP0xQ=
Endpoint = vpn-2a0ae5c1.ungleich.ch:51820
AllowedIPs = ::/0
PersistentKeepalive = 25
EOF

Notice that you would need to adapt the Address in the [Interface] section to the prefix they assign to you and maybe the PublicKey and Endpoint in the [Peer] section to the corresponding endpoint settings.

This will generate a private key and the settings that you will need, I commented out the lines that enable you to run custom scripts as PostUp and PreDown hooks

However, your interface is not up yet, for that we use wg-quick up wg-ungleich.

And that’s it!(*) Your interface is up! Check ip addr show wg-ungleich and you will see the interface has been created and your IPv6 prefix has been assigned to it.

In order to know how your tunnel is doing though, you want to run the wg command, which should show something like this:

$ wg
interface: wg-ungleich
  public key: vwYkUOZdGA5akEA1VkPg/sS7hvdcA0Lf8MxpTOQdcHE=
  private key: (hidden)
  listening port: 37834
  fwmark: 0xca6d

peer: hi60lGP+xEUQ+kVnqA7PlJAO1SVqTS1W36g0LhFP0xQ=
  endpoint: [185.203.114.153]:51820
  allowed ips: ::/0
  transfer: 0 B received, 296 B sent
  persistent keepalive: every 25 seconds

(*) Well, that wasn’t really it! Notice how we have not received any bytes? As easy as this is, we haven’t told ungleich about our public key!

Go do that and once they set it up, the connection will be fully established and you will have full IPv6 connectivity.

Conclusions

WireGuard is refreshingly neat and well documented, the tooling works just as expected (a very-good-thing-tm) and the tunnel is very stable.

Right now, getting one of these VPNs at ungleich requires human interaction, but this has the potential of being fully automated and I wouldn’t be surprised if they end up doing that.

Also, human interaction is not all that terrible, in fact, in many cases it is a feature because you get to learn and share, while having better support than fully automated systems.

Maybe now it’s time for you to check that ungleich quiz v6.

But right now for us at Camilion, it’s time to go back to growing our infrastructure and polishing our nearly-ready upcoming that will join those we already offer.