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 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.
Update: their crowdfunding is over now, you can read about it
here
and get the VPN on their new IPv6 shop.
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 https://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.
