New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Networking issues while using VPN #416

Open
esabelhaus opened this Issue May 23, 2016 · 76 comments

Comments

Projects
None yet
@esabelhaus

esabelhaus commented May 23, 2016

I've tried approaching this two different ways.

Create VPN Within Windows

  • Instantiate VPN tunnel using AnyConnect VPN client on my Windows laptop, then connect to upstream devices using SSH via Linux subsystem.
  • RESULT: DNS was not properly handed off to the linux subsystem, and no hostname resolution is possible.

Create VPN Connection Within Subsystem

  • Instantiate VPN tunnel using OpenConnect networking client
  • RESULT: Failed to instantiate network tunnel with the following error
    mkdir: cannot create directory ‘/dev/net’: No such file or directory

Any help would be greatly appreciated, as I often perform work on VMs which are located behind a firewall of some sort

@tastle73

This comment has been minimized.

Show comment
Hide comment
@tastle73

tastle73 May 23, 2016

Same thing with OpenVPN

tastle73 commented May 23, 2016

Same thing with OpenVPN

@benhillis benhillis added the network label May 24, 2016

@esabelhaus

This comment has been minimized.

Show comment
Hide comment
@esabelhaus

esabelhaus May 25, 2016

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

esabelhaus commented May 25, 2016

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
@saschagehlich

This comment has been minimized.

Show comment
Hide comment
@saschagehlich

saschagehlich Jun 20, 2016

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

saschagehlich commented Jun 20, 2016

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

@sunilmut

This comment has been minimized.

Show comment
Hide comment
@sunilmut

sunilmut Jun 20, 2016

Member

@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.

Member

sunilmut commented Jun 20, 2016

@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.

@esabelhaus

This comment has been minimized.

Show comment
Hide comment
@esabelhaus

esabelhaus Jun 21, 2016

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 commented Jun 21, 2016

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

@jwsloan

This comment has been minimized.

Show comment
Hide comment
@jwsloan

jwsloan Aug 12, 2016

@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?

jwsloan commented Aug 12, 2016

@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?

@esabelhaus

This comment has been minimized.

Show comment
Hide comment
@esabelhaus

esabelhaus Aug 12, 2016

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

esabelhaus commented Aug 12, 2016

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

@jwsloan

This comment has been minimized.

Show comment
Hide comment
@jwsloan

jwsloan Aug 12, 2016

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?

jwsloan commented Aug 12, 2016

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?

@esabelhaus

This comment has been minimized.

Show comment
Hide comment
@esabelhaus

esabelhaus Aug 12, 2016

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.

esabelhaus commented Aug 12, 2016

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.

@aseering

This comment has been minimized.

Show comment
Hide comment
@aseering

aseering Aug 12, 2016

Contributor

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.

Contributor

aseering commented Aug 12, 2016

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.

@jwsloan

This comment has been minimized.

Show comment
Hide comment
@jwsloan

jwsloan Aug 13, 2016

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!

jwsloan commented Aug 13, 2016

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!

@jwsloan

This comment has been minimized.

Show comment
Hide comment
@jwsloan

jwsloan Aug 13, 2016

@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!

jwsloan commented Aug 13, 2016

@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!

@ericblade

This comment has been minimized.

Show comment
Hide comment
@ericblade

ericblade Aug 22, 2016

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..)

ericblade commented Aug 22, 2016

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..)

@rodrymbo

This comment has been minimized.

Show comment
Hide comment
@rodrymbo

rodrymbo Aug 22, 2016

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.

rodrymbo commented Aug 22, 2016

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.

@ericblade

This comment has been minimized.

Show comment
Hide comment
@ericblade

ericblade Aug 22, 2016

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

ericblade commented Aug 22, 2016

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

@tyoungjr

This comment has been minimized.

Show comment
Hide comment
@tyoungjr

tyoungjr Sep 21, 2016

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

tyoungjr commented Sep 21, 2016

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

@ewan-fanduel

This comment has been minimized.

Show comment
Hide comment
@ewan-fanduel

ewan-fanduel Sep 25, 2016

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

ewan-fanduel commented Sep 25, 2016

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

@jwsloan

This comment has been minimized.

Show comment
Hide comment
@jwsloan

jwsloan Sep 25, 2016

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

jwsloan commented Sep 25, 2016

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

@ewan-fanduel

This comment has been minimized.

Show comment
Hide comment
@ewan-fanduel

ewan-fanduel Sep 26, 2016

@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 commented Sep 26, 2016

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

@tyoungjr

This comment has been minimized.

Show comment
Hide comment
@tyoungjr

tyoungjr Sep 27, 2016

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

tyoungjr commented Sep 27, 2016

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

@ericblade

This comment has been minimized.

Show comment
Hide comment
@ericblade

ericblade Sep 27, 2016

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)

ericblade commented Sep 27, 2016

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)

@matthiassb

This comment has been minimized.

Show comment
Hide comment
@matthiassb

matthiassb Oct 12, 2016

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 commented Oct 12, 2016

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.

@sunilmut

This comment has been minimized.

Show comment
Hide comment
@sunilmut

sunilmut Oct 12, 2016

Member

@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.

Member

sunilmut commented Oct 12, 2016

@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.

@matthiassb

This comment has been minimized.

Show comment
Hide comment
@matthiassb

matthiassb Oct 12, 2016

@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

matthiassb commented Oct 12, 2016

@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

@bitcrazed

This comment has been minimized.

Show comment
Hide comment
@bitcrazed

bitcrazed Nov 10, 2016

Collaborator

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

Collaborator

bitcrazed commented Nov 10, 2016

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

@regisbsb

This comment has been minimized.

Show comment
Hide comment
@regisbsb

regisbsb May 20, 2017

Why is it closed mate? @benhillis

regisbsb commented May 20, 2017

Why is it closed mate? @benhillis

@benhillis

This comment has been minimized.

Show comment
Hide comment
@benhillis

benhillis May 20, 2017

Member

Sorry was doing cleanup of things marked as fixed.

Member

benhillis commented May 20, 2017

Sorry was doing cleanup of things marked as fixed.

@benhillis benhillis reopened this May 20, 2017

@rwngallego

This comment has been minimized.

Show comment
Hide comment
@rwngallego

rwngallego May 24, 2017

I'm still having this problem in the Creators Update. If I manually add the VPN DNS to the top of the /etc/resolv.conf list, then it cannot do the correct resolution to the external IP addresses and I can't do neither apt-get update nor apt-get install

rwngallego commented May 24, 2017

I'm still having this problem in the Creators Update. If I manually add the VPN DNS to the top of the /etc/resolv.conf list, then it cannot do the correct resolution to the external IP addresses and I can't do neither apt-get update nor apt-get install

@timcanham

This comment has been minimized.

Show comment
Hide comment
@timcanham

timcanham Jun 4, 2017

I confirmed that a full tunnel with Pulse Secure allows WSL programs to see the hosts on the other side of the tunnel.

timcanham commented Jun 4, 2017

I confirmed that a full tunnel with Pulse Secure allows WSL programs to see the hosts on the other side of the tunnel.

@rwngallego

This comment has been minimized.

Show comment
Hide comment
@rwngallego

rwngallego Jun 6, 2017

Could you please up vote the resolution for this issue in the following almost related User Voice entry?

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/15636564-vpn-routing-support-in-bash

rwngallego commented Jun 6, 2017

Could you please up vote the resolution for this issue in the following almost related User Voice entry?

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/15636564-vpn-routing-support-in-bash

@trondhindenes

This comment has been minimized.

Show comment
Hide comment
@trondhindenes

trondhindenes Jul 20, 2017

I just noticed that with OpenVPN active on my Windows client, I'm loosing all name resolution functionality inside WSL - nothing works. With Pulse VPN, the only affected traffic was the traffic supposed to traverse the tunnel.

Hopefully there will be some movement here, the VPN-related problems is the sole reason I still have to fire up a Linux VM in most cases.

trondhindenes commented Jul 20, 2017

I just noticed that with OpenVPN active on my Windows client, I'm loosing all name resolution functionality inside WSL - nothing works. With Pulse VPN, the only affected traffic was the traffic supposed to traverse the tunnel.

Hopefully there will be some movement here, the VPN-related problems is the sole reason I still have to fire up a Linux VM in most cases.

@javydekoning

This comment has been minimized.

Show comment
Hide comment
@javydekoning

javydekoning Nov 2, 2017

Can confirm that I have this issue as well when connected to VPN (Build: 10.0.16299)

javydekoning commented Nov 2, 2017

Can confirm that I have this issue as well when connected to VPN (Build: 10.0.16299)

@diveyez

This comment has been minimized.

Show comment
Hide comment
@diveyez

diveyez Mar 14, 2018

No updates on this?

diveyez commented Mar 14, 2018

No updates on this?

@mathieulongtin

This comment has been minimized.

Show comment
Hide comment
@mathieulongtin

mathieulongtin Apr 26, 2018

Still an issue two years later.

mathieulongtin commented Apr 26, 2018

Still an issue two years later.

@odhekar

This comment has been minimized.

Show comment
Hide comment
@odhekar

odhekar May 1, 2018

I updated to 1803 today and this problem still exists 😐

odhekar commented May 1, 2018

I updated to 1803 today and this problem still exists 😐

@bliles

This comment has been minimized.

Show comment
Hide comment
@bliles

bliles May 3, 2018

Explained very well by @rodrymbo, just to reiterate:
Please allow the Windows resolver to provide a DNS resolver service to the Linux environment. Then the Linux environment just always points to that DNS service. Everything will just work and stay in sync. The upstream resolver will just look like a standard DNS server to the Linux environment.

bliles commented May 3, 2018

Explained very well by @rodrymbo, just to reiterate:
Please allow the Windows resolver to provide a DNS resolver service to the Linux environment. Then the Linux environment just always points to that DNS service. Everything will just work and stay in sync. The upstream resolver will just look like a standard DNS server to the Linux environment.

@mikchaos

This comment has been minimized.

Show comment
Hide comment
@mikchaos

mikchaos May 5, 2018

mikchaos commented May 5, 2018

@rfgamaral

This comment has been minimized.

Show comment
Hide comment
@rfgamaral

rfgamaral May 6, 2018

@mikchaos It worked for me too. Thank you :)

Now I need to find a way to monitor this file for changes and move such line automatically if it's found on the bottom.

Unfortunately for me, even if this is fixed, it will be for Insiders builds only and I cannot install such builds on my work machine.

rfgamaral commented May 6, 2018

@mikchaos It worked for me too. Thank you :)

Now I need to find a way to monitor this file for changes and move such line automatically if it's found on the bottom.

Unfortunately for me, even if this is fixed, it will be for Insiders builds only and I cannot install such builds on my work machine.

@jjacode

This comment has been minimized.

Show comment
Hide comment
@jjacode

jjacode Jun 12, 2018

This issue seems to still exist. I cannot use my company's vpn in WSL either. But it just doesn't work at all. There is never a time it works and then stops. I've tried uninstalling and reinstalling, then doing the same on another machine. But WSL doesn't seem to pick up the DNS once connected.

jjacode commented Jun 12, 2018

This issue seems to still exist. I cannot use my company's vpn in WSL either. But it just doesn't work at all. There is never a time it works and then stops. I've tried uninstalling and reinstalling, then doing the same on another machine. But WSL doesn't seem to pick up the DNS once connected.

@bliles

This comment has been minimized.

Show comment
Hide comment
@bliles

bliles Jun 12, 2018

I've resorted to using http://maradns.samiam.org/deadwood/ as a tiny DNS service running in Windows and then setting /etc/resolv.conf in WSL with:

nameserver 127.0.0.1

In the dwood3rc.txt I have these upstream servers defined:

upstream_servers = {}
upstream_servers["vpn-domain1."]="...ip of vpn domain1 DNS..."
upstream_servers["vpn-domain2."]="...ip of vpn domain2 DNS..."
upstream_servers["."]="8.8.8.8" # Use Google for other stuff

Some notes about using deadwood:

  • You have to have '.' at the end of any domain you specify
  • If your VPN domain IP addresses are private/non-routable ranges like 10.0.0.0/8 or 192.168.0.0/16 you need to have the deadwood setting filter_rfc1918 = 0

bliles commented Jun 12, 2018

I've resorted to using http://maradns.samiam.org/deadwood/ as a tiny DNS service running in Windows and then setting /etc/resolv.conf in WSL with:

nameserver 127.0.0.1

In the dwood3rc.txt I have these upstream servers defined:

upstream_servers = {}
upstream_servers["vpn-domain1."]="...ip of vpn domain1 DNS..."
upstream_servers["vpn-domain2."]="...ip of vpn domain2 DNS..."
upstream_servers["."]="8.8.8.8" # Use Google for other stuff

Some notes about using deadwood:

  • You have to have '.' at the end of any domain you specify
  • If your VPN domain IP addresses are private/non-routable ranges like 10.0.0.0/8 or 192.168.0.0/16 you need to have the deadwood setting filter_rfc1918 = 0
@macmiranda

This comment has been minimized.

Show comment
Hide comment
@macmiranda

macmiranda Jun 24, 2018

What if your DNS servers change for each VPN connection that you establish?
The workaround would still require you to edit the config file and reload deadwood.
Not the best solution.
Why can't wsl just pick up the IP addresses in the same order as:
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses

macmiranda commented Jun 24, 2018

What if your DNS servers change for each VPN connection that you establish?
The workaround would still require you to edit the config file and reload deadwood.
Not the best solution.
Why can't wsl just pick up the IP addresses in the same order as:
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses

@bliles

This comment has been minimized.

Show comment
Hide comment
@bliles

bliles Jun 24, 2018

@macmiranda, I agree it's not a perfect solution. My recommendation to fix this is a DNS service provided by the OS to WSL that would hand off DNS resolution.

However the situation you mentioned is not a problem. If you have multiple VPNs it seems unlikely that two or more VPNs would use the same DNS zones. You can just configure all your zones in Deadwood. Obviously only the connected VPN zone will work, but it doesn't hurt to have a configured DNS server that is unreachable when you aren't trying to resolve those addresses.

bliles commented Jun 24, 2018

@macmiranda, I agree it's not a perfect solution. My recommendation to fix this is a DNS service provided by the OS to WSL that would hand off DNS resolution.

However the situation you mentioned is not a problem. If you have multiple VPNs it seems unlikely that two or more VPNs would use the same DNS zones. You can just configure all your zones in Deadwood. Obviously only the connected VPN zone will work, but it doesn't hurt to have a configured DNS server that is unreachable when you aren't trying to resolve those addresses.

@gosukiwi

This comment has been minimized.

Show comment
Hide comment
@gosukiwi

gosukiwi Jul 4, 2018

Unfortunately @mikchaos solution doesn't work for me. Maybe I'm running an old build? Is that on Insiders only for now? My version is 10.0.17134 Build 17134

gosukiwi commented Jul 4, 2018

Unfortunately @mikchaos solution doesn't work for me. Maybe I'm running an old build? Is that on Insiders only for now? My version is 10.0.17134 Build 17134

@Bagorolin

This comment has been minimized.

Show comment
Hide comment
@Bagorolin

Bagorolin Jul 9, 2018

The same issue also appears whn using DirectAccess. This is very annoying. I also prefer a solution where the subsystem just uses the windows dns entries...

Bagorolin commented Jul 9, 2018

The same issue also appears whn using DirectAccess. This is very annoying. I also prefer a solution where the subsystem just uses the windows dns entries...

@asreimer

This comment has been minimized.

Show comment
Hide comment
@asreimer

asreimer Jul 17, 2018

Just adding my vote towards the WSL using the same dns entries as windows.

asreimer commented Jul 17, 2018

Just adding my vote towards the WSL using the same dns entries as windows.

@therealkenc

This comment has been minimized.

Show comment
Hide comment
@therealkenc

therealkenc Jul 17, 2018

Collaborator

I also prefer a solution where the subsystem just uses the windows dns entries...

So people are aware of the architecture, "WSL" does not know a "DNS entry" coming down port 53 from ssh session data coming down port 22 or a streaming YouTube video coming down port 443. Neither does a Real Linux™ kernel. The resolver functionality is provided by glibc (on for example Ubuntu) and musl (on for example Alpine). WSL doesn't know a DNS cache entry from Adam.

One can hypothesise alternative architectures. Perhaps lookups are always bounced off a local server on localhost along the lines of @bliles back a few posts. Or perhaps Microsoft ships a re-imagination of systemd-resolved that dynamically updates /etc/resolv.conf as Windows VPN connections come and go. Or Microsoft ships their own nss-resolve plug-in. None of these are straightforward asks however, to articulate let alone implement. There is no (quoth) "just uses" about it.

In any event, there is an ask for a resolution (cough) to the broad problem in some unspecified way on UserVoice here. The place to "add your vote" would be there; please do not fill up this issue with me2s.

Collaborator

therealkenc commented Jul 17, 2018

I also prefer a solution where the subsystem just uses the windows dns entries...

So people are aware of the architecture, "WSL" does not know a "DNS entry" coming down port 53 from ssh session data coming down port 22 or a streaming YouTube video coming down port 443. Neither does a Real Linux™ kernel. The resolver functionality is provided by glibc (on for example Ubuntu) and musl (on for example Alpine). WSL doesn't know a DNS cache entry from Adam.

One can hypothesise alternative architectures. Perhaps lookups are always bounced off a local server on localhost along the lines of @bliles back a few posts. Or perhaps Microsoft ships a re-imagination of systemd-resolved that dynamically updates /etc/resolv.conf as Windows VPN connections come and go. Or Microsoft ships their own nss-resolve plug-in. None of these are straightforward asks however, to articulate let alone implement. There is no (quoth) "just uses" about it.

In any event, there is an ask for a resolution (cough) to the broad problem in some unspecified way on UserVoice here. The place to "add your vote" would be there; please do not fill up this issue with me2s.

@asreimer

This comment has been minimized.

Show comment
Hide comment
@asreimer

asreimer Jul 17, 2018

One can hypothesise alternative architectures. Perhaps lookups are always bounced off a local server on localhost along the lines of @bliles back a few posts. Or perhaps Microsoft ships a re-imagination of systemd-resolved that dynamically updates /etc/resolv.conf as Windows VPN connections come and go. Or Microsoft ships their own nss-resolve plug-in. None of these are straightforward asks however, to articulate let alone implement. There is no (quoth) "just uses" about it.

Everything you have hypothesized falls under what users mean when they say WSL should be "just using" the windows dns entries. The point is, however it's accomplished, this behaviour is what users expect. @bliles solution is the closest we can get right now, but this would be much better as something built in to WSL.

Thanks for pointing to the UserVoice. I've voted there. Cheers.

asreimer commented Jul 17, 2018

One can hypothesise alternative architectures. Perhaps lookups are always bounced off a local server on localhost along the lines of @bliles back a few posts. Or perhaps Microsoft ships a re-imagination of systemd-resolved that dynamically updates /etc/resolv.conf as Windows VPN connections come and go. Or Microsoft ships their own nss-resolve plug-in. None of these are straightforward asks however, to articulate let alone implement. There is no (quoth) "just uses" about it.

Everything you have hypothesized falls under what users mean when they say WSL should be "just using" the windows dns entries. The point is, however it's accomplished, this behaviour is what users expect. @bliles solution is the closest we can get right now, but this would be much better as something built in to WSL.

Thanks for pointing to the UserVoice. I've voted there. Cheers.

@regisbsb

This comment has been minimized.

Show comment
Hide comment
@regisbsb

regisbsb Jul 23, 2018

I've summed up all the workarounds here:

First run on powershell:

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

Then run bash on windows with either ubuntu or bash commands (depending on your installation)

Edit the /etc/resolv.conf and replace all nameserver {ip} with the ones generated by the top one.

You should have internet and intranet back now. Remove the first line to make it permanent but be aware if you change networks it will not update anymore. (back it up first maybe?)

Maybe someone could automate that?

regisbsb commented Jul 23, 2018

I've summed up all the workarounds here:

First run on powershell:

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

Then run bash on windows with either ubuntu or bash commands (depending on your installation)

Edit the /etc/resolv.conf and replace all nameserver {ip} with the ones generated by the top one.

You should have internet and intranet back now. Remove the first line to make it permanent but be aware if you change networks it will not update anymore. (back it up first maybe?)

Maybe someone could automate that?

@matthiassb

This comment has been minimized.

Show comment
Hide comment
@matthiassb

matthiassb Jul 23, 2018

I took my previous Powershell suggestion and wrapped it in an init.d script. For those interested, here is the Gist

@regisbsb

matthiassb commented Jul 23, 2018

I took my previous Powershell suggestion and wrapped it in an init.d script. For those interested, here is the Gist

@regisbsb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment