Wandering Thoughts archives

A realization about our VPN and IPv6 traffic

At work, we operate a VPN for our users. The VPN is used to access both internal resources inside our networks and university resources that are normally only available from 'on-campus' IP addresses. Because of the latter, and for historical reasons, our VPN servers are configured to tell VPN clients to route all of their traffic through the VPN, regardless of the destination. In other words, the VPN makes itself the default route for traffic. Today, in the process of investigating an unfortunate Google decision, I realized that there's an important qualification on that statement.

(We actually support two different sorts of VPNs, OpenVPN and L2TP, and have two servers for each type, but all of this is a technical detail. Conceptually, we have 'a VPN service'.)

We and our networks are IPv4 only; we haven't even started to implement IPv6, and it will probably be years before we do. Naturally this means that our VPN is IPv4 only, so its default route only applies to IPv4 traffic, which means that all of the client's IPv6 traffic bypasses our VPN. All of the IPv4 traffic flows through the VPN, but if your client has a working local IPv6 connection, any IPv6 traffic will go through it.

The first consequence of this is for traffic to places outside the university. An increasing number of ISP networks provide IPv6 addresses to people's devices, many of those devices prefer IPv6 where possible, and an increasing number of sites are reachable over IPv6. Connections from people's devices to those sites don't go through our VPN. But if you move the same device over to a network that only provides it an IPv4 address, suddenly you're going through our VPN to reach all of those sites. This makes troubleshooting apparent VPN based connection problems much more exciting than before; we may have to disable IPv6 during our tests, and we may have to find out if a user who's having problems has an IPv6 connection.

The second consequence is that some day some of the university's on-campus websites may start to have IPv6 addresses themselves. Traffic to these websites from IPv6 capable clients that are connected to the VPN will mysteriously (to people) be seen as outside traffic by those on-campus websites, because it's coming directly from the outside client over IPv6 instead of indirectly through our VPN over IPv4. There are also some external websites that have historically given special permissions to the university's IPs. If these websites are IPv6 enabled and your client is IPv6 enabled, they're going to see you as a non-university connection even with the VPN up.

There probably isn't anything we can sensibly do about this. I think it would be a bad idea to try to have our VPN servers grab all client IPv6 traffic and block it, even if that's possible. Among other things, there are probably IPv6 only ISPs out there that this would likely interact very badly with.

(Our VPN isn't officially documented as a privacy aid for general Internet usage, although people may well use it as that. So I don't consider it a security issue that the current configuration leaks people's real IPv6 addresses to sites.)

Some notes on building Firefox from source on Ubuntu

I'm accustomed to being able to build an Ubuntu packaged program from its upstream source by doing 'apt-get build-dep <package>' and then following the upstream's build process (well, for the version that Ubuntu packages; later versions may have additional dependencies). Ubuntu packages the latest version of Firefox on all LTS releases because it has no real choice. This forces Ubuntu to update Rust to relatively current versions even on LTS releases, and in theory it should force Ubuntu to also package and update all of the other programs, which would let us just build from the upstream source of the current Firefox. As I've learned the hard way, this doesn't work, even if you've used rustup to have your own copy of Rust and Cargo. Today I spent a bit of time digging into the deb/* control files and patches in the Ubuntu 18.04 Firefox source package, and now I understand more about how to do this.

If you try to build Firefox from source on 18.04 even for Firefox 78 ESR, you will almost immediately run into an issue where the Ubuntu 18.04 version of nodejs is far too old (this isn't the only issue you'll hit if you try to build Firefox 78). There's also the problem that you can't build support for AV1 video because the 18.04 version of nasm is also too old. It turns out that Ubuntu has packaged special, more up to date versions of both of these just for building Firefox, as the nasm-mozilla and nodejs-mozilla packages. To tell your own Firefox build to use them, you need to set two options in your .mozconfig:

ac_add_options NODEJS=/usr/lib/nodejs-mozilla/bin/node
ac_add_options NASM=/usr/lib/nasm-mozilla/bin/nasm

(The Ubuntu 18.04 template mozconfig used in a source package build is mozconfig.in. You may find it interesting to look through, depending on what your objectives are in building Firefox from source on Ubuntu. The full Debian control directory is here.)

Ubuntu 18.04 has a further trick that's relevant if you haven't set up your own versions of Rust and Cargo, which is that in their relax-cargo-dep.patch they lower the necessary version of Cargo down to the version they package on 18.04, which is one version behind their Rust (currently Rust 1.47.0 but Cargo 1.46.0; the versions are normally in sync).

Ubuntu 20.04's mozconfig.in still uses the nodejs-mozilla version of nodejs, but it no longer needs a special NASM version (at least for now). It also still has the relax-cargo-dep.patch. The overall Ubuntu 20.04 Debian control directory is here. I'm a little bit surprised that Ubuntu hasn't yet been forced to update both Rust and Cargo on 18.04 and 20.04, but it's probably coming in some future Firefox release. Firefox is very enthusiastic about requiring quite current versions of both.

(Firefox Nightly recently switched to require Rust 1.51.0 (and thus the same version of Cargo). The current Firefox Beta source tree, here, still seems to only require 1.47.0; see python/mozboot/mozboot/util.py. The bump in Nightly is from bug #1715282, which has a discussion of what has triggered it.)

My personal view is that if you're building the current released version of Firefox from source, you should probably use your own Rust and Cargo (from Rustup). This spares you from having to patch in a special case to accept an older Cargo, so all you need is the build-deps and the one or two .mozconfig settings (two on 18.04, but just the nodejs on 20.04 for now).

(And in the future if Firefox stops building from source for me on whatever Ubuntu LTS I care about at the time, at least I now have written down some starting points for investigation.)