%3CLINGO-SUB%20id%3D%22lingo-sub-1764074%22%20slang%3D%22en-US%22%3EWindows%20Subsystem%20for%20Linux%202%20-%20Addressing%20Traffic%20Routing%20Issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1764074%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSTRONG%3EThe%20Problem%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3ESo%20recently%20I%20was%20trying%20to%20run%20some%20kubectl%20commands%20using%20WSL2%20to%20my%20home%20K8S%20cluster%20and%20encountered%20some%20strange%20events.%20Everything%20had%20worked%20fine%20when%20using%20WSL%20but%20for%20some%20reason%20I%20could%20now%20only%20ping%20external%20devices%20to%20my%20laptop%20(Router%2C%20Switch%2C%20Printer%20etc).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EMy%20Configuration%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3ESo%20just%20for%20clarification%20I%20have%20my%20configuration%20set%20like%20this.%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EMy%20local%20network%20runs%20a%20192.168.1.0%2F24%20subnet.%3C%2FLI%3E%0A%3CLI%3EMy%20laptop%20runs%20as%20192.168.1.10.%3C%2FLI%3E%0A%3CLI%3EHyper-V%20installed%20on%20the%20laptop.%3C%2FLI%3E%0A%3CLI%3EWSL2%20installed%20and%20running%20Ubuntu%2018.04.%3CUL%3E%0A%3CLI%3EWSL%20vSwitch%20configured%20in%20Hyper-V%20Virtual%20Switch%20Manager%20as%20%22Internal%20Network%22.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3CLI%3EHyper-V%20configured%20with%20a%20dedicated%20vSwitch%20for%20Kubernetes%20(K8s-Switch).%3CUL%3E%0A%3CLI%3ESet%20as%20%22Internal%20Network%22.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3CLI%3E3%20x%20Ubuntu%2018.04%20Kubernetes%20VMs%20configured%20below.%3CUL%3E%0A%3CLI%3Ek8s-master-01%20(10.10.10.101%2F24).%3C%2FLI%3E%0A%3CLI%3Ek8s-worker-01%20(10.10.10.111%2F24).%3C%2FLI%3E%0A%3CLI%3Ek8s-worker-02%20(10.10.10.112%2F24).%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EThe%20worker%20and%20the%20nodes%20are%20all%20configured%20to%20route%20traffic%20correctly%20and%20can%20actively%20ping%20my%20host%20and%20resolve%20external%20domains.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EThe%20Investigation%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EAfter%20conducting%20some%20internet-based%20investigation%2C%20I%20found%20discovered%20I%20was%20not%20the%20only%20person%20seeing%20this%2C%20and%20an%20issue%20was%20already%20raised%20on%20GitHub%20under%20the%20Microsoft%2FWSL%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fmicrosoft%2FWSL%2Fissues%2F4288%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fgithub.com%2Fmicrosoft%2FWSL%2Fissues%2F4288%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThere%20are%20some%20great%20discussions%20around%20the%20subject%20on%20here%2C%20but%20for%20anyone%20who%20wants%20to%20know%20the%20resolution%20that%20worked%20for%20me%2C%20keep%20reading.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EThe%20Resolution%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EAfter%20trying%20a%20few%20different%20suggestions%2C%20the%20best%20resolution%20I%20have%20found%20is%20listed%20by%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fjonaskuske%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ejonaskuke.%3C%2FA%3E%3C%2FP%3E%0A%3CP%3EEssentially%2C%20we%20needed%20to%20set%20Forwarding%20to%20be%20enabled%20across%20the%20two%20v-Switches.%20Using%20this%20command%20(with%20admin%20rights)%20based%20on%20my%20v-Switch%20names%20works.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-powershell%22%3E%3CCODE%3EGet-NetIPInterface%20%7C%20where%20%7B%24_.InterfaceAlias%20-eq%20'vEthernet%20(WSL)'%20-or%20%24_.InterfaceAlias%20-eq%20'vEthernet%20(K8s-Switch)'%7D%20%7C%20Set-NetIPInterface%20-Forwarding%20Enabled%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThere%20are%20some%20discussions%20around%20post%20reboot%20persistency%20as%20it%20appears%20the%20setting%20is%20discarded%20post%20reboot%2C%20which%20may%20be%20due%20to%20the%20WSL%20v-Switch%20taking%20a%20while%20to%20imitate.%20However%2C%20keep%20this%20command%20in%20a%20.ps1%20file%20and%20all%20is%20good.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1764074%22%20slang%3D%22en-US%22%3E%3CP%3EWSL2%20traffic%20not%20routing%20to%20local%20Hyper-V%20vSwitches%3F%20Check%20this%20out!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22Windows_Subsystem_for_Linux_2-Addressing_Traffic_Routing_Issues.png%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F226302iB60C20ADB348FEAB%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20role%3D%22button%22%20title%3D%22Windows_Subsystem_for_Linux_2-Addressing_Traffic_Routing_Issues.png%22%20alt%3D%22Windows_Subsystem_for_Linux_2-Addressing_Traffic_Routing_Issues.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1764074%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EChris%20Jeffrey%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EPowerShell%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Microsoft

The Problem

So recently I was trying to run some kubectl commands using WSL2 to my home K8S cluster and encountered some strange events. Everything had worked fine when using WSL but for some reason I could now only ping external devices to my laptop (Router, Switch, Printer etc).

 

My Configuration

So just for clarification I have my configuration set like this.

  • My local network runs a 192.168.1.0/24 subnet.
  • My laptop runs as 192.168.1.10.
  • Hyper-V installed on the laptop.
  • WSL2 installed and running Ubuntu 18.04.
    • WSL vSwitch configured in Hyper-V Virtual Switch Manager as "Internal Network".
  • Hyper-V configured with a dedicated vSwitch for Kubernetes (K8s-Switch).
    • Set as "Internal Network".
  • 3 x Ubuntu 18.04 Kubernetes VMs configured below.
    • k8s-master-01 (10.10.10.101/24).
    • k8s-worker-01 (10.10.10.111/24).
    • k8s-worker-02 (10.10.10.112/24).

The worker and the nodes are all configured to route traffic correctly and can actively ping my host and resolve external domains.

 

The Investigation

After conducting some internet-based investigation, I found discovered I was not the only person seeing this, and an issue was already raised on GitHub under the Microsoft/WSL https://github.com/microsoft/WSL/issues/4288.

 

There are some great discussions around the subject on here, but for anyone who wants to know the resolution that worked for me, keep reading.

 

The Resolution

After trying a few different suggestions, the best resolution I have found is listed by jonaskuke.

Essentially, we needed to set Forwarding to be enabled across the two v-Switches. Using this command (with admin rights) based on my v-Switch names works.

 

 

 

Get-NetIPInterface | where {$_.InterfaceAlias -eq 'vEthernet (WSL)' -or $_.InterfaceAlias -eq 'vEthernet (K8s-Switch)'} | Set-NetIPInterface -Forwarding Enabled

 

 

 

There are some discussions around post reboot persistency as it appears the setting is discarded post reboot, which may be due to the WSL v-Switch taking a while to imitate. However, keep this command in a .ps1 file and all is good.