Skip to main content

Curious case of Cisco AnyConnect and WSL2

One thing Covid has taught me is the importance of VPN. Also one other thing COVID has taught me while I work from home is that your Windows Machine can be brilliant as long as you have WSL2 configured in it.

So imagine my dismay when I realized I cannot access my University resources while being inside the University provided VPN client.



Both of the institutions I have affiliation with, requires me to use VPN software which messes up WSL2 configuration (which of course I realized at 1:30 AM). Don't get me wrong, I have faced this multiple times last two years (when I was stuck in India), and mostly I have been lazy and bypassed the actual problem by side-stepping with my not-so-noble alternatives, which mostly include one of the following:
  • Connect to a physical machine exposed to the internet and do an ssh tunnel from there (not so reliable since this is my actual box sitting at lab desk, also not secure enough)
  • Create a poor man's socks proxy in that same box to have my own VPN (OpenVPN and wireguard both works fine with WSL2). Again a security nightmare if IT guy finds out
  • And my least favorite method, use Putty
Tonight though high on 7 coffee, I decided to take a shot at it finally to figure out what the heck is even going on with this AnyConnect scenario. Lo and behold a google search reveals thousands of complaints and even more solutions (most of which didn't work for me).

So I ended up cobbling together the solution which worked for me. Actually, two solutions since it seem the most efficient one is only working for one of my machines and not the other one, for which I had to choose an even more esoteric way.

So hopefully one of these will work for you.

Method 1: Auto-manually rewrite WSL2's DNS config by getting the VPN values 

There of course is a manual solution. But whats the fun in that. Just download or copy paste this gist inside your WSL2 instance. A lot of this has been taken from this Github issue https://github.com/microsoft/WSL/issues/1350#issuecomment-844452775

Download vpn-fix.sh 

#!/bin/bash

echo "Getting current DNS servers, this takes a couple of seconds"

/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -Command '
$ErrorActionPreference="SilentlyContinue"
Get-NetAdapter -InterfaceDescription "Cisco AnyConnect*" | Get-DnsClientServerAddress | Select -ExpandProperty ServerAddresses
Get-NetAdapter | ?{-not ($_.InterfaceDescription -like "Cisco AnyConnect*") } | Get-DnsClientServerAddress | Select -ExpandProperty ServerAddresses
' | \
        awk 'BEGIN { print "# Generated by vpn-fix on", strftime("%c"); print } { print "nameserver", $1 }' | \
        tr -d '\r' > /etc/resolv.conf

clear
Mark it as executable
sudo chmod a+x vpn-fix.sh
Now just run this using sudo ./vpn-fix.sh
And you should something like this
You can automate so that this gets called everytime you open WSL. Not to mess with VPN again and again. Note, you will have to run it after you have connected via anyconnect.

Method 2: Use the awesome gvisor-tap-vsock to tunnel your connection

This utilizes the awesome wsl-vpn toolkit. Since this uses a lot of third party code and was a bit overkill, I did not prefer this initially. But one of my machines did not update the resolve conf even after I restarted the wsl backend multiple times, so I had to go this path (that one has kali linux on it instead of ubuntu)

Just follow the below procedure

# download wsl-vpnkit
VERSION=v0.3.x
wget https://github.com/sakai135/wsl-vpnkit/releases/download/$VERSION/wsl-vpnkit.tar.gz
tar --strip-components=1 -xf wsl-vpnkit.tar.gz app/wsl-vpnkit files/wsl-gvproxy.exe files/wsl-vm
rm wsl-vpnkit.tar.gz

# place Windows exe
USERPROFILE=$(wslpath "$(powershell.exe -c 'Write-Host -NoNewline $env:USERPROFILE')")
mkdir -p "$USERPROFILE/wsl-vpnkit"
mv wsl-gvproxy.exe "$USERPROFILE/wsl-vpnkit/wsl-gvproxy.exe"

# place Linux bin
chmod +x wsl-vm
sudo chown root:root wsl-vm
sudo mv wsl-vm /usr/local/sbin/wsl-vm

# run the wsl-vpnkit script
chmod +x wsl-vpnkit
sudo ./wsl-vpnkit

This should get your VPN and WSL2 working again.
Labels:

Comments

Post a Comment

Popular posts from this blog

Racecraft (Project Koru) · Prologue — The Origin Story

Racecraft · Prologue , The Origin Story It Started With a Wine List and a Question About Racing How a happy-hour conversation in the Bay Area turned into a trustable AI race coach , and then into a second version that runs entirely on a phone, on the NPU. This is the prologue to a five-part series. Two years ago(1st November, 2024) I was in the Bay Area for a GDE Summit. If you've never been: it's a couple of days of talks among Google Developer Experts, the kind of people who get unreasonably excited about a new on-device runtime, and then , mercifully , a happy hour where everyone stops performing and just eats. We ended up at a restaurant(Puesto Santa Clara), a long table of GDEs, and I was doing the most important engineering of the evening: trying to decide which wine to order. Across the table was Ajeet Mirwani . I don't even remember how the wine talk turned into racing talk , these things drift , but the moment the word "racing" ...
Post a Comment
Read more

A Split‑Brain Neuro‑Symbolic Training Method for High‑Velocity Autonomous Coaching from Telemetry

 Author: Rabimba Karanjai Scope: Problem statement + data methodology + model training (no deployment discussion) Abstract Real‑time coaching in motorsport is a safety‑critical learning problem : a system must map noisy, high‑frequency telemetry to short, actionable guidance that remains physically consistent and avoids hazardous recommendations . This paper proposes a “Split‑Brain” training formulation that separates (i) a semantic coaching target (what action/critique should be expressed) from (ii) a reflexive interface (how actions are represented as compact, verifiable tokens). The approach trains a Small Language Model (SLM) in the Gemma family [1] using QLoRA fine‑tuning [2] , and introduces a telemetry tokenizer plus teacher‑student synthesis pipeline to generate instruction‑action pairs at scale. Core contribution: a reproducible method to convert “ golden lap ” differential tel...
Post a Comment
Read more

The Throughput Trap: Benchmarking vLLM on OpenXLA and the Reality of Production LLM Serving

vLLM Systems · DevLab 2026, Deep Dive I was recently invited by the Google TPU team to speak at the OpenXLA Summer DevLab 2026 . This post breaks down our deep-dive evaluation of the matured vLLM + OpenXLA stack, the fundamental engineering mismatches between CUDA and XLA serving paths, and why traditional capacity metrics are lying to you. If you are operating large language models at enterprise scale right now, your platform architecture team is likely staring at a massive infrastructure crossroads: Should we migrate our core serving workloads from GPUs to TPUs? Historically, NVIDIA's CUDA ecosystem was the only serious option for user-facing, low-latency LLM generation. But here in 2026, the economics and infrastructure options have transformed. Google TPUs are highly available, cheaper per chip, and the open-source serving stack built around vLLM and OpenXLA has officially achieved absolute production readiness. Yet, when our infrast...
Post a Comment
Read more