Same thing with OpenVPN

For the time being, it is possible to manually configure host names in /etc/hosts, but long run this is not a reliable solution unfortunately.

ex:

127.0.0.1    localhost.localdomain
192.168.1.1  my.host.name
192.168.1.2  some.other.host.name

This is an important issue and pretty much the only thing that holds me back from switching from Mac back to Windows

@esabelhaus - Thanks for providing this feedback. Regarding "Create VPN Within Windows" scenario, were the right entries not getting populated in /etc/hosts automatically?

Regarding "VPN Connection Within Subsystem", unfortunately, WSL currently does not support '/dev/net'. If that is an important scenario for you (and @saschagehlich), please help us prioritize that providing that feedback through our User Voice Page.

specifically, when the VPN is running on my windows machine, the linux subsystem was not properly handling host name resolution, while my windows machine was. It would appear to be DNS related at that point.

This symptom occurs both when starting the subsystem before or after I have instantiated my VPN connection. IP addresses do resolve, but the host name resolution eg /etc/hosts does not properly handle the new dns providers which are passed in from the VPN device on windows

@esabelhaus, am I understanding correctly that you were able to get around this issue? If so, could you please elaborate on your fix for someone who isn't as familiar with /etc/hosts and the like?

Here is a decent reference for how /etc/hosts works.
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap9sec95.html

The gist is, you're mapping an IP address to a hostname, and at startup, the Ubuntu based linux subsystem is reading in the configuration file /etc/hosts and using that information to map networking to a hostname. Everything must be routed over TCP/IP, so we're telling the linux host that:

10.0.0.2    my.host.name

would allow me to ssh into 10.0.0.2 using the hostname my.host.name using the command ssh user@my.host.name

You can sort of understand why this is not a reasonable workaround, because it requires you to manually configure your host configuration for any hostname which you must access within the VPN subnet.

Hope that explanation helps!

-Haus

That definitely helps! Not too complicated at all.

Unfortunately, that didn't fix my issue.

I'm using ruby and net/http to send a POST request to a URL behind the VPN.

While connected to VPN, I used nslookup to find the IP of the host I'm trying to connect to.
I edited /etc/hosts to include that IP and host.
I then run my ruby code (which works through the windows command line).
I get a 404 response in WSL.

Do you see something I might be missing?

try running dig my.host.name on your host, and see whether the IP address is what you have referenced in your /etc/hosts config

Also, if you've got access to the host behind the firewall directly, maybe tail the logs server side to see whether the resource is actually available, going off the 404 error.

For what it's worth, a 404 error means that you did successfully connect to the server in question (which is all that /etc/hosts has control over) but that host is reporting that the particular page that you requested doesn't exist.

Is it possible that you made a typo in the hostname? Or otherwise didn't type it exactly as it appears / is used (including prefixes like "www.", etc). If you did, and if your remote server is using SNI, this would cause it to route you incorrectly.

You could also try using curl or wget, or installing VcXsrv and running firefox, to browse the server manually from within WSL.

Your instructions for installing VcXsrv are fantastic! Thank you for that. I am able to run firefox, but it gets a 404 page as well. I get the same 404 page whether I am connected to VPN or not.

I take the same URL and paste it into Chrome running in Windows, and the page works.

Any other thoughts? Thank you very much for your time, by the way!

@aseering, you were right all along. Firefox from WSL was a big help figuring it out.

In the end it was pretty simple. I put the wrong IP address in /etc/hosts. It was a public URL and not the 192.168... IP. Once I fixed that, I was able to make the connection. Thanks, and I can't wait for @bitcrazed and team to get this particular kink worked out!

One thing you can do, if the software you need is capable of operating entirely through a proxy server, is setup a ssh tunnel with proxy on the host, and then use that. I can use that with Firefox in WSL to connect to sites on my work network .. I have a ssh tunnel setup on localhost that goes through another machine which is actually connected to VPN.

The problem that I have, is that I can't connect with anything but firefox, since there's no real way to force Linux to connect to everything through a SOCKS5 Proxy (unlike with Windows and Mac, there are several softwares out there that make that happen) ... as far as I've ever been able to find ... so every individual piece of software needs to be configured to use it.

So, the configuration that I use:

One (Linux) machine connected to VPN (also handles a host of other tasks, but it's basically a server box -- sits in a closet, and is only operated via remote). My primary Windows computer. Windows computer has a program called MobaXTerm installed, which provides ssh, tunnel, proxy, and X server (among many other things!). Windows also has a program called Proxifier that routes literally everything destined for a host on the other side of the VPN through a ssh tunnel socks5 proxy. Configure a ssh tunnel/socks5 proxy in MobaXTerm to go through the Linux box. Works great in Windows. In WSL, configure Firefox to use the proxy. That also works great, but also sends all traffic through the work VPN, which is not really acceptable, and is part of why I use this configuration.

The part that confuses me, is that WSL is completely unable to see the other side of the VPN tunnel. (Coincidentally, neither is Microsoft Edge -- both seem to bypass the DLL injection that Proxifier does, which makes them kind of bad citizens .. although I can justify it more in my head for WSL than for Edge..)

One primary problem reported by the OP (@esabelhaus) is that DNS changes in Windows (e.g. by a VPN) do not get reflected to the /etc/resolv.conf in real time on WSL. Add to this that WINS resolution isn't configured into WSL at all by default (currently).

Even to veteran linux users, when DNS isn't working, it "feels" like IP networking has failed, and that's how it frequently gets reported, when just fixing DNS would get things going again. Since Windows is providing the routing table and retworking devices (transparently), having /etc/resolv.conf set up once per session, and with the DNS resolver settings of just one network adapter (I think), leads to many situations where DNS fails for WSL and with it the "feeling" that networking is broken.

Here's a suggestion: set up the Windows resolver to allow WSL to use it (connecting via UDP and TCP), so /etc/resolv.conf can list localhost as the resolver. That way all of the networking (devices, pseudo-devices, routing, DNS, etc) would be going through Windows, and problems in WSL would show up as problems in Windows, and fixing them in Windows via Windows tools would resolve them in WSL.

I'd expect that to be a much nicer UX.

Setting things up so WSL is handling all networking (interfaces, iptables/firewall/routing, DNS, VPN, tun/tap, etc; perhaps even dhcp and vpn protocols) is flexible but fairly complex, and, likely, everything on the Windows side would have to be replicated to the WSL side. So I wouldn't be disappointed if the current philosophy of "passing networking off to Windows" was maintained. Letting the local Windows do DNS resolution via /etc/resolv.conf would be straightforward and a "linuxy" way to handle DNS, at least from a user's point of view, and wouldn't require trying to keep /etc/resolv.conf (or /etc/hosts) up to date in real time as things change on the Windows side.

Sounds like a good idea. DNS isn't the root of my problem, unfortunately, but I'd welcome the improvements.

@aseering That's pretty wild ... X Windows on Windows.

Still having the same issue as @esabelhaus (subsystem ignoring any Windows VPN connection), has there been any update on this?

@ewan-fanduel have you tried manually editing your /etc/hosts file?

@jwsloan I can yep, but the hosts I work with change often so it's a bit of hassle to keep updating it manually :/

@ewan-fanduel that sucks, does your router support dynamic DNS[https://en.wikipedia.org/wiki/Dynamic_DNS]?

editing hosts doesn't work for my situation, because i'm routing the traffic destined for VPN through a ssh tunnel to end up going through another computer that is connected to the VPN directly. WSL traffic completely ignores the routing performed by the Proxifier app in Windows. (so does Microsoft Edge, also .. these are things that shouldn't be possible, IMO)

Just to toss in some information.

This issue arises for me when split tunneling is enabled. It looks like WSL uses the nameservers related to the default route with the lowest metric.

I changed the metric for the default route of the VPN to make it lower than the one for my LAN. After doing this the nameservers in /etc/resolv.conf switched orders with the ones related to the VPN interfaces at the top. However of course due to split tunnelling I can no longer access the public net with this configuration.

Win10 doesn't suffer from this issue. Even with a higher metric on the default route Windows still prioritizes using the VPN connections DNS servers.

@matthiassb - Thanks for reporting the issue. We are aware of our shortcomings in supporting VPN, and are looking into it. Meanwhile, if you are familiar with what needs to be enabled on the Linux user-mode (resolver daemons?) to better support VPN, do let us know.

@sunilmut - I'm not sure what can be done via Linux user-mode. Perhaps using something like dnsmasq could help but I see that needing to be configured per domain, etc.

I'm not sure how resolvconf get's passed the IPs from the windows space. I do see that the following PS command accurately represents the order of the DNS servers.

Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses

Perhaps the underlying mechanism for the above command can be passed to resolvconf or whatever daemon is managing the DNS system in WSL

@sunilmut While you're looking into this, could you please explore supporting DirectAccess too?

@cantrell - that's disappointing. These suggestions for 'use the version from the Windows Store app' are well intentioned but not necessarily helpful. An enterprise that offers their standardized image Cisco AnyConnect offers whatever bits Cisco provides. It isn't a simple matter to simply swap that out for something from the app store.

If there is something known to be different in the store version - that's something we can refer to the good folks who manage the VPN.

Thank you, @regisbsb. I just set up a VPN connection through Windows using AnyConnect (from the app store) as the VPN provider, and it works!

@blakeduffey: Yeah, our VPN installation process also installs certificates, so I assumed I couldn't use the version from the app store. But when I connected to the VPN server, I was given the option to download and install the necessary certificates. It's a pain to have to deviate from my company's IT policy, but it does appear to work.

Thanks, all!

@cantrell @regisbsb - thanks very much for the feedback. I'll start down this rabbit hole myself. :)

It's interesting looking back to see this is still an active issue 4 years later.

I fixed the problem by going to the AnyConnect Settings -> Preferences -> Allow local (LAN) access when using VPN

Name resolution and everything else worked fine in WSL once I enabled this.

Please see my comment regarding conflict with IPv6 DNS servers here: #1350 (comment)

A workaround is suggested.

The problem seems to be with the dns resolver. If dns is routed through the vpn it fails. Adding my vpn dns server to the wsl distro's resolv.conf fixes things.

@lassimus

The problem seems to be with the dns resolver. If dns is routed through the vpn it fails. Adding my vpn dns server to the wsl distro's resolv.conf fixes things.

Can you check if you have IPv6 enabled, paste the output of your /etc/resolv.conf (VPN connected), apply the workaround mentioned below, and tell if that worked for you ?
#1350 (comment)

As a workaround, if I start wsl(2), then disconnect/reconnect to my VPN, DNS requests start working again (and continues to work until I restart). If I start WSL before connecting to my VPN, it works the first time.

@donatelloOo

Can you check if you have IPv6 enabled, paste the output of your /etc/resolv.conf (VPN connected), apply the workaround mentioned below, and tell if that worked for you ?
#1350 (comment)

Your ipv6 method didn't work for me. I disabled ipv6 on all interfaces, and after different combinations of restarting things, /etc/resolv.conf is still the autogen version. I'm using a WireGuard vpn connection, which seems to be different from most others on this thread. Manually adding another entry to /etc/resolv.conf works fine for me. Without the entry, enabling the vpn kills all dns in wsl, not just vpn related lookups. Hopefully this feedback helps!

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.22.144.1

I recently tried to use openvpn on WSL, and after a day of digging, discovered this GH issue. Kinda depressing that it's been four years and there's still not a fix.

All I want to do is this:

$ openvpn --config path/to/config.ovpn

And I get an error:

Fri Feb  5 19:18:37 2021 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Fri Feb  5 19:18:37 2021 Exiting due to fatal error

@craigloewen-msft Is this still something coming down the pipeline? It doesn't sound like anyone has a workable solution for CLI + openvpn. Thanks in advance.

Since my last reply I have done a clean install of Windows on a new SSD. Now on 20H2 build 19042.867 (a few ahead compared to before). My Windows and WSL2 configs are very vanilla. It seems I'm having the same issue as before. Alas, it seems to have been a fluke. 😥 The only work around I have found is to launch WSL BEFORE connecting to my work VPN (with AnyConnect on the DTLSv1.2 protocol). The WSL networking really needs to work properly and inherit all the settings from Windows in real time, without requiring a restart of WSL or Windows, or reconnecting to the VPN.

Moving back to WSL1, WSL2 is kind of hopeless, if they cannot fix this in 4 years, I guess its not going to get fixed any sooner. WSL1 works like a charm with VPN

I fixed the problem by going to the AnyConnect Settings -> Preferences -> Allow local (LAN) access when using VPN

Name resolution and everything else worked fine in WSL once I enabled this.

Which version of AnyConnect are you using? I don't have that option on my Preferences page in AnyConnect 4.9.01095

I fixed the problem by going to the AnyConnect Settings -> Preferences -> Allow local (LAN) access when using VPN
Name resolution and everything else worked fine in WSL once I enabled this.

Which version of AnyConnect are you using? I don't have that option on my Preferences page in AnyConnect 4.9.01095

I am using 4.9.06037 version, anyconnect version

Allow local (LAN) access is usually disabled by companies. This is usually to avoid viruses from other computers on your network from scanning and infecting other computers on your cooperate network.

Allow local (LAN) access is usually disabled by companies. This is usually to avoid viruses from other computers on your network from scanning and infecting other computers on your cooperate network.

This comment is insightful and continues to to be a point lost on some - if Microsoft wants WSL to be an accepted solution in a corporate environment, the network solution needs to work with the 'corporate approved' VPN solution. Many (most?) corporate users can't swap out the AnyConnect client, can't make changes to said client, etc.

This issue has been open for 4+ years. Split tunnel VPN remains a problem. Depending how I configure the WSL /etc/resolv.conf - I can either resolve the the corporate network or the public internet - but never both.

I'm not sure if this is an issue with the DNS resolving to an ipV6 address or something.
Without the vpn connected (PureVPN):
I can connect to my server.

With the vpn connected:
Fails to connect

I then added in the ipV4 address that came up in my wsl /etc/hosts file for my server

<IPV4 address> my.server

and tried connecting to the server again, and it worked.

Seems to be an issue with the DNS resolution. Just my two cents

(I'm not even close to a network engineer though)

I'm using WSL1 and still encountering this. Anytime you disconnect or connect to VPN, I'll need to terminate the WSL instance and then restart it before I can connect to remote URLs again in WSL.

wget www.google.com
--2021-09-30 18:01:23--  http://www.google.com/
Resolving www.google.com (www.google.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘www.google.com’

Any updates?

When I connect to my employer's VPN from Windows, WSL mostly still works correctly. There are no DNS issues and most network activity is normal. There are, however, specific network activities that fail often. Pulls and pushes to/from Github hang frequently, and I have to retry them or disable the VPN temporarily. If I use VSCode remote into WSL while the VPN is on, the extensions panel that shows what is installed inside the remote fails to load. Turning the VPN off and the extensions panel loads perfectly.

I was trying to get around these issues by connecting to the VPN from within WSL instead of from Windows, but that does not seem to even be possible.

Use wsl-vpnkit.

Background

Docker Desktop for Windows uses something called VPNKit to provide network connectivity to VMs while connected to a VPN.

From https://github.com/moby/vpnkit#why-is-this-needed:

Running a VM usually involves modifying the network configuration on the host, for example by activating Ethernet bridges, new routing table entries, DNS and firewall/NAT configurations. Activating a VPN involves modifying the same routing tables, DNS and firewall/NAT configurations and therefore there can be a clash -- this often results in the network connection to the VM being disconnected.

VPNKit, part of HyperKit attempts to work nicely with VPN software by intercepting the VM traffic at the Ethernet level, parsing and understanding protocols like NTP, DNS, UDP, TCP and doing the "right thing" with respect to the host's VPN configuration.

VPNKit operates by reconstructing Ethernet traffic from the VM and translating it into the relevant socket API calls on OSX or Windows. This allows the host application to generate traffic without requiring low-level Ethernet bridging support.

The wsl-vpnkit project takes VPNKit from Docker Desktop for Windows and uses it to provide network connectivity for WSL 2 that works nicely with VPN.

@rfdonnelly

The wsl-vpnkit project takes VPNKit from Docker Desktop for Windows and uses it to provide network connectivity for WSL 2 that works nicely with VPN.

Last wsl-vpnkit versions uses gvisor-tap-vsock, see sakai135/wsl-vpnkit#91

Hi folks, we have put out a new update that aims to address networking issues in WSL. In your .wslconfig file you can set experimental.networkingMode=mirrored, as well as some other key settings that should improve your network compatibility! Please try them out and let us know what you think.

More info on this release and the changes can be found here in the blog post.

Please note: You need to be on a Windows Insiders version to use the new networking settings (Any channel of Windows Insiders will do, including release preview). If you see the "These are not supported" messages it means that your current Windows version doesn't have support, and you will need to upgrade. These features will eventually be coming to Windows 11 22H2.

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

These new networking features are now available on the latest version of Win11 22H2!

Please make sure you're on the latest build to get these features, you can do that by clicking "Check for Updates" in Windows settings. You can check you have the right build by either ensuring you have KB5031354 installed, or run cmd.exe /c ver and ensure that your build number is 22621.2428 or higher (Including the minor build number which is after the . as this was a backport!)

Doesn't seem like that's true 🤔

Windows log:

Unknown key 'experimental.dnsTunneling' in C:\Users\...\.wslconfig:12

Windows specifications:

Edition	Windows 11 Enterprise
Version	22H2
Installed on	‎04/‎10/‎2023
OS build	22621.2428
Experience	Windows Feature Experience Pack 1000.22674.1000.0

Hi folks, we have put out a new update that aims to address networking issues in WSL. In your .wslconfig file you can set experimental.networkingMode=mirrored, as well as some other key settings that should improve your network compatibility! Please try them out and let us know what you think.

More info on this release and the changes can be found here in the blog post.

Please note: You need to be on a Windows Insiders version to use the new networking settings (Any channel of Windows Insiders will do, including release preview). If you see the "These are not supported" messages it means that your current Windows version doesn't have support, and you will need to upgrade. These features will eventually be coming to Windows 11 22H2.

Nice! Is there a plan to add mirrored to Windows 10 as well?
I am sure a lot of corporate-managed laptop owners would love not having that wsl-vpnkit machine.