[TriLUG] Home VPN?

[Cristóbal Palmer via TriLUG]

On Tue, Feb 18, 2025, at 20:22, Matthew Glassman via TriLUG wrote:
> How difficult and precarious is it to set up a home VPN

As with so many things, what you want to consider will vary immensely with what you’re trying to accomplish. While it's unlikely your goals are fully aligned with mine, I thought I’d share a tripping hazard of VPN use that I hit yesterday with my work. Maybe it will save someone here some time.

Like many folks, my employer runs a VPN, both hardware and software, that grants access to on-site resources to folks (students, faculty, staff) connecting from other networks like home or a conference hotel. Also like many folks, I worked from home yesterday (Wednesday) because of the snow, and used the work-provided VPN. Unlike most of you, I scheduled a morning zoom call with a student worker (also working from home) who just started in our lab, and the goal was to introduce this young adult to one or more ways to run virtualized web applications locally on the workstation in the lab that we set up last week.

So we're both connected to the VPN, which in our case gives us addresses in a subnet that the central networking group has carved out of 172.16/12. Let's say for the sake of this email that my VPN-allocated IPv4 addr was 172.17.31.20 and the student's was 172.17.31.21. Also important to this discussion are two additional network details. My lab makes extensive use of IPv6, so all the student workstations, nearly all the production VMs, and all the lab utility VMs have IPv6 addresses in one of several VLANs. I had a shell on one of these utility VMs, from which I could run ansible commands on the student's workstation. Crucially, the employer-provided VPN does _not_ provide IPv6 access.

After some initial conversation and discussion of terms like paravirtualization, and some fumbling with zoom controls to have the student share their screen, we set out to follow a recipe to install (on the student's workstation) a webapp that ships as a docker image[0]. Some of you may already see where this is going. We got to step 5 in the install recipe, which includes:

    sudo apt install docker.io
    sudo apt install git

And the student's shell hung during the install and eventually their ssh connection to the workstation timed out. Meanwhile, I could still connect from the utility VM. What's happening here? 

[ break for socratic reflection; recency bias red herring pursued by the author omitted ]

Well, if you consult the docker docs[1], you'll find some ranges in use that overlap with our VPN. Specifically, the "bip" value was something like 172.17.0.1/16. The fix, then, was to write an /etc/docker/daemon.json file that looks like this:

    {
      "bip" : "192.168.76.1/24"
    }

and restart services. Tada! All fixed for the student. Still, this feels a bit ugly. Every time we install/deploy docker, we have to remember to set the bip value in daemon.json. Possibly we could/should capture that in ansible and always use ansible to deploy, but surely there's something better? Well, I'm not in a position to tell my employer what to do, but it looks like others have tripped on things like this and have a fix:

  https://www.bowtie.security/blog/so-you-want-to-smuggle-a-subnet-into-an-airport

The above blog post was fun reading for me because it is confirmation of arguments I've made in the past (Use IPv6!!). Maybe one of y'all has deployed bowtie and can chime in with your experience, or maybe this will inspire you to do that and I can buy you a beverage in exchange for the chance to ask you questions about your experience.

Warmly,
CMP

[0] https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md
[1] https://docs.docker.com/reference/cli/dockerd/