Since using Fiber7, I was having issues with IPv6 connectivity using OpenWrt. Debugging revealed that Init7’s IPv6 server sets the DHCPv6 Unicast option along with a unicast address, but does not respond when using unicast addressing to renew the lease 20 minutes later. The lease then expires and breaks IPv6 connectivity.
A DHCPv6 server can choose to announce the unicast option, but if announced, the server is supposed to reply to unicast requests. So this seems to be a misbehaving DHCPv6 server. Luckily, the DHCPv6 client shipped with OpenWrt 18.06 now comes with a workaround (odhcp6c: add noserverunicast config option for broken DHCPv6 servers). The option noserverunicast ignores any advertised server unicast addresses and continues using multicast. Init7’s DHCPv6 server seems to answer renew requests using multicast just fine, providing stable IPv6 connectivity.
To enable this workaround, add the following line to the IPv6 WAN interface:
Googles Compute Engine VMs which are configured preemptible are massively cheaper than regular VMs, typically a fourth or even a fifth of the price of a regular machine. It seems quite lucrative for everything which is not mission critical.
However, it can be quite annoying when all state gets lost. Luckily Google does not just turn off the machine but sends an ACPI G2 Soft-Off signal. With Debian 9 (stretch) the ACPI daemon is processing the ACPI signals (acpid) and by default shuts down the machine. This post shows how to use hibernate instead.
Note: Since Google might start the machine on a different (virtual) hardware resuming the machine might not succeed, or even worse, lead to adverse effects. In practice, it seems to work quite well for me 🙂
This weekend I finally came around to create OpenEmbedded recipes for WireGuard. The recipe currently awaits review and hopefully will get part of the meta-networking layer, part of the meta-openembedded repository of the upstream OpenEmbedded project. There are two recipes, one for the kernel module and one for the user space tools. The user space tools have the kernel module as a dependency, hence it is sufficient to install the wireguard-tools package, e.g. by using IMAGE_INSTALL_append in your local.conf:
IMAGE_INSTALL_append = " wireguard-tools"
The kernel module needs at least a kernel version 3.18 or later and has some requirements regarding kernel configuration. The WireGuard website maintains a list of kernel requirements. If you are using the Yocto kernel, the netfilter kernel feature (features/netfilter/netfilter.scc) is enabled by default and seems to be sufficient to run WireGuard. To get started with WireGuard, refer to the excellent Quick Start guide on wireguard.io.
Today I upgrading my router to LEDE 17.01 and played a bit with IPv6 and WireGuard VPN tunnels. My Internet connection at home (connected via Cable to the Comcast network) has decent IPv6 support, which I wanted to enjoy also when on the road, using non-IPv6 networks. The first step is to setup a Wireguard tunnel, which I already did some months ago (Dan Lüdtke, author of the LEDE/OpenWrt web interface plugin for Wireguard has a good post on that. Update April: Dan has a new post which does not make use of the stacked approach. This is suitable for lots of regular setups. However, the IPv6 address setup with automatic network assignment described here is only supported by using stacked interfaces, hence this article keeps using that configuration). In my setup the Wireguard IPv4 network uses a network from the private range (192.168.2.0/24) to route IPv6 traffic. For IPv6 my goal was to assign a public subnet, so I can access the IPv6 network without any NAT directly through the tunnel. In IPv6 world, NAT is a technology which is not commonly used/considered deprecated anyway. Note that this how-to does not route the IPv4 traffic to the internet through the VPN tunnel, only IPv6 traffic.
First, a large enough IPv6 prefix needs to be available on the router in order to assign two independent IPv6 networks to my local LAN and the Wireguard VPN. One has to realize that in IPv6 world, subnets are by definition between /49 and /64. One cannot create a subnet /72 or similar since the last 64 bits are the host portion, reserved exclusively for host addresses. By default, LEDE requested a 64 bit IPv6-prefix from the provider, but this can be changed in the WAN6 network interface settings:
My new provider IPv6 connectivity, however after connecting my OpenWrt based WNDR4300 (using Chaos Calmer 15.05-rc3) things unfortunately did not “just work”… This post summarize some hints how to debug IPv6 on OpenWrt.
First, make sure that the upstream (WAN) interface is configured according to the documentation in the OpenWrt Wiki. Using LuCI, you have to create a new interface (WAN6) which should c