Splitting Network Paths with Two NICs to Get CUDA Working on RTX 5060 under WSL2 on Windows 11

Introduction While setting up CUDA for an RTX 5060 GPU on Windows 11 + WSL2, I ran into a somewhat unusual situation: The PC has two physical Ethernet adapters. The first one is connected to the main corporate/office network, which regular traffic (e.g. email) needs to keep using. The second one is connected to a separate "lab" LAN, and I wanted WSL2 to use that network for apt, CUDA, and pulling Ollama models. With WSL2's default networking (NAT mode), WSL just borrows whatever single route Windows itself is using, so there's no clean way to keep "business traffic" and "lab traffic" on two separate physical paths. This post describes how I used a Hyper-V virtual switch together with networkingMode=bridged in .wslconfig to split the paths so that: Windows itself only uses the main corporate network, and WSL2 joins the lab LAN directly and gets its own IP address there. All organization names, hostnames, IP addresses, and MAC addresses in this post have been anonymized / replaced with placeholder values. IPv4 ranges use 192.0.2.0/24 / 198.51.100.0/24 / 203.0.113.0/24, and IPv6 uses 2001:db8::/32 — all of these are reserved specifically for documentation use by RFC 5737 and RFC 3849. Environment Windows 11 Pro (build 10.0.26300-ish) GPU: NVIDIA GeForce RTX 5060 WSL2 (Ubuntu) CUDA 13.3 A PC with two physical NICs (referred to below as "NIC1" / "Ethernet" and "NIC2" / "Ethernet 2") What I wanted (architecture) +-------------------------+ | Windows 11 | | | Email, etc. ---+-- NIC1 (Ethernet) | Main corporate network | 203.0.113.10/24 | GW: 203.0.113.1 | | | NIC2 (Ethernet 2) | | v Hyper-V virtual switch (WSL-LAN2) | v bridged +----------|--------------+ | +------v------+ | WSL2 | Lab LAN | (Ubuntu) | 192.168.1.x/24 (DHCP) | CUDA 13.3 | DNS: 192.168.1.1 +-------------+ The key idea is to give each physical NIC a distinct role: NIC1 ("Ethernet") — used directly by Windows itself. All of the normal traffic (email, etc.) goes through here. NIC2 ("Ethernet 2") — bridged through a Hyper-V virtual switch, with Windows itself excluded from that network. Only WSL2 (bridged onto that switch) gets to use the lab LAN directly. Steps 1. Create a Hyper-V virtual switch for NIC2 From an elevated PowerShell prompt, create an external switch bound to NIC2 ("Ethernet 2"): New-VMSwitch -Name "WSL-LAN2" -NetAdapterName "Ethernet 2" -AllowManagementOS $false -AllowManagementOS $false is the key flag here. It tells Hyper-V that Windows itself should not join this virtual switch's network (the lab LAN). Only guests bridged onto this switch — in our case, WSL2 — get to use it. If the switch already exists, you can apply the same setting afterward: Set-VMSwitch -Name "WSL-LAN2" -AllowManagementOS $false 2. Configure bridged networking in .wslconfig Add the following to %UserProfile%\.wslconfig: [wsl2] networkingMode=bridged vmSwitch=WSL-LAN2 This bridges WSL2 onto the WSL-LAN2 switch we just created, so WSL2 will pick up its own IP address via DHCP from the lab LAN. It's worth making a backup copy of .wslconfig before editing it, so you can diff against it or roll back later. 3. Restart WSL to apply the change wsl --shutdown Then start WSL again. 4. Point WSL's DNS at the lab LAN Set the lab LAN's DNS server (here, as an example, 192.168.1.1) in /etc/resolv.conf inside WSL: nameserver 192.168.1.1 5. Verify Check that WSL picked up an address on the lab LAN and can reach the outside world over HTTP: wsl -u root sh -c "ip -4 addr show eth0; curl -sI http://archive.ubuntu.com | head -1" If you see a 192.168.1.x address and HTTP/1.1 200 OK, WSL is successfully routing through the lab LAN. On the Windows side, ipconfig should show only the main corporate network's gateway — no 192.168.1.x address should appear there: ipconfig Ethernet adapter Ethernet: IPv4 Address . . . . . . . . . . . : 203.0.113.10 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 203.0.113.1 Ethernet adapter vEthernet (Default Switch): (This is the internal adapter Hyper-V creates by default. It has no gateway, so it doesn't affect this setup.) It's also worth double-checking name resolution and connectivity on the Windows side, to make sure regular traffic (e.g. mail) isn't affected: Resolve-DnsName www.example.com Test-NetConnection 203.0.113.1 6. Install CUDA With WSL2 now able to reach the outside world (apt repos, Ollama's model distribution, etc.) over the lab LAN, install CUDA as usual (CUDA 13.3 in this case). The CUDA install steps themselves inside WSL2 don't depend on which NIC the traffic goes out through. Gotchas If Windows accidentally joins the lab LAN, its default gateway can switch over to the lab LAN, breaking regular traffic such as email that depends on the main corporate network. Make sure to pass -AllowManagementOS $false to New-VMSwitch / Set-VMSwitch to keep Windows out of that network. vEthernet (Default Switch) is an internal adapter that Hyper-V creates by default and has no gateway, so it doesn't interfere with this setup — it's fine to ignore it even though it's a bit alarming to see a new adapter appear. DNS caching can hold onto stale results after switching networks, so it's a good idea to run ipconfig /flushdns after making the change. ipconfig /flushdns Reverting If you want to undo this setup, two steps will take you back to where you started: Remove-VMSwitch -Name "WSL-LAN2" -Force [wsl2] networkingMode=None (Having a backup copy of .wslconfig makes it easy to diff and restore.) Summary WSL2's networkingMode=bridged combined with a Hyper-V virtual switch lets you split network paths between "the path Windows itself uses" and "the path WSL uses" — useful on PCs with two physical NICs. The key is -AllowManagementOS $false on New-VMSwitch / Set-VMSwitch, which excludes Windows itself from that network so only the bridged WSL guest uses it. This is a fairly niche setup specific to machines with two NICs, so hopefully it helps someone else in the same situation. Next step: use this lab-network setup to run some LLM evaluation tests with Ollama. I may write that up separately if there's interest.