Hi all, Sorry to revive this topic, but it seems I bumped in the same case, and despite digging in a lot of places, I haven't found any positive solution to my problem. To clarify the case, I believe the pulse configuration is Split tunneling enabled and All routes tunneled. This is the first configuration listed on https://docs.pulsesecure.net/WebHelp/PDC/9.0R1/Content/PDC_AdminGuide_9.0R1/Pulse_Split_Tunneling_Summary.htm An evidence of this is that if I ping the WSL gateway from the WSL Linux, it doesn't work. But if I suspend the tunnel (which is a possible exception of this configuration) it works during the time of suspension. Hence, the internal WSL network seems categorized as local network, just as a physical network. Another evidence, is: if I manually change the Windows internal route for the WSL adapter and reenable its configuration as without VPN, the connexion works again for a few seconds before being changed again. In the row below, 172.21.96.1 is the IP address of the WSL gateway as seen in Windows. route print 172.21.* (...) 172.21.96.0 255.255.240.0 On-link 10.89.94.42 1 <-------------- Routed on VPN end-point address 172.21.96.1 255.255.255.255 On-link 172.21.96.1 271 route change 172.21.96.0 mask 255.255.240.0 172.21.96.1 metric 10 Yet, this workaround is no good, because with this routing, the WSL Linux instance traffic is routed outside the VPN. What is expected is: - for the internal virtual network to work normally, espeially the gateway delivers DNS to the Linux WSL instance, so it must be reachable; - for Linux access to the external network to be NATted by the virtual switch, and routed through VPN, just as any other connexion from the Windows host.   Is there a way to distinguish between local physical network and local virtual networks in the Pulse configuration? Am I missing something in the WSL2 / Hyper-V configuration that would provide the intended behaviour?   Thanks for any idea. ... View more