Skip to content
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.

Sign up for GitHub

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

Jump to bottom

VPN still problematic #2082

Closed
bigteejay opened this issue May 9, 2017 · 43 comments
Closed

VPN still problematic #2082

bigteejay opened this issue May 9, 2017 · 43 comments
Labels
network

Comments

@bigteejay
Copy link

bigteejay commented May 9, 2017 •
edited

Background

Why does networking not work when connected to VPN when VPN /etc/resolv.conf entries are lower, but works (connected to VPN or not) when VPN entries appear before non-VPN entries? Contrary to what appears to be indicated here and here, I must still follow the advice here to manually edit /etc/resolv.conf to move the VPN entries to the top, then all works well. It seems that it tries all the entries when VPN is first (non-VPN DNS is utilized, after a brief pause, when disconnected from DNS with edited resolv.conf.)

Windows build number

  • Microsoft Windows [Version 10.0.15063]

What is happening

  • What you're doing and what's happening:
  1. Updated Windows to Creator
  2. Upgraded Cisco VPN Client ("Cisco AnyConnect Secure Mobility Client") to version 4.4.02039
  3. Upgraded WSL when disconnected from VPN, successfully...
    $ lsb_release -d
    Description: Ubuntu 16.04.2 LTS
  4. Check /etc/resolv.conf
$ cat /etc/resolv.conf                                                                            
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 84.200.69.80 # Home DNS1
nameserver 8.8.8.8  # Home DNS2
nameserver fec0:0:0:ffff::1
search Home
  1. Close Bash
  2. Connect to VPN in Windows (ensure it is working)
  3. Check /etc/resolv.conf again
$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 84.200.69.80 # Same
nameserver 8.8.8.8 # Same
nameserver X.X.X.X # VPN DNS1
search Home americas.company.pvt # VPN FQDN
  1. Open Bash and try networking, and it fails...
$ ping google.com
ping: unknown host google.com

What works

  • What's wrong / what should be happening instead:
  1. Disconnect VPN
  2. Reopen Bash
  3. Try again, works without issue
$ ping google.com
PING google.com (108.177.96.102) 56(84) bytes of data.
64 bytes from eh-in-f102.1e100.net (108.177.96.102): icmp_seq=1 ttl=42 time=170 ms
64 bytes from eh-in-f102.1e100.net (108.177.96.102): icmp_seq=2 ttl=42 time=163 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2000ms
rtt min/avg/max/mdev = 163.385/167.009/170.634/3.647 ms
  1. Alternatively, edit /etc/resolv.conf
    $ sudo nano /etc/resolv.conf
  2. Remove auto-gen comment line and move VPN entries to top (should the system not continue to work its way down if upper entries fail?)
$ cat /etc/resolv.conf
nameserver X.X.X.X	# VPN DNS1
nameserver X.X.X.X	# VPN DNS2
search Home americas.company.pvt # VPN FQDN
nameserver 84.200.69.80 # Home DNS1
nameserver 8.8.8.8 # Home DNS2

Straces
@sunjoong
Copy link

@bigteejay - Might be it different returning google.com's IP address of "nslookup google.com X.X.X.X" (VPN DNS1) from "nslookup google.com 84.200.69.80" (Home DNS1)?

@bigteejay
Copy link
Author

@sunjoong - I'm not (yet) following you.

Are you asking if perhaps the two different DNS systems are returning different IP's and that is causing the failure? I would think it would just land on the first successful attempt to look it up?

google.com was just what I used as an easy repo/example (problem was first noticed trying to use wget, then via sudo apt-get update as well.)

@sunjoong
Copy link

@bigteejay - I mean... I read you could ping google.com when you use X.X.X.X, but coud not when 84.200.69.80. So, I had a curiosity of difference.

@bigteejay
Copy link
Author

@sunjoong - Ah, I think you misunderstand.

From bullet point 4 in "Whats happening" above, with my default DNS settings from my home router (during which 84.200.69.80 is the primary DNS as indicated in the content of /etc/resolv.conf depicted above) I can ping just fine (google.com. otherwise.)

It is the default state of /etc/resolv.conf after I connect to my company's VPN, depicted in bullet 7 in "Whats happening" above, in which my VPN/company DNS info is appended to the bottom. In this situation, unedited/unchanged (84.200.69.80 still listed first), that I then no longer have internet access (ping fails.)

Disconnecting from VPN (which causes /etc/resolv.conf to revert back to bullet point 4) or editing resolv.conf to match 5 from "What works"... then allows networking to function again.

@sunjoong
Copy link

@bigteejay - Hmm... Different problem from #1881 ? I had thought same kind. I think, in #1881, problem is on DNS.

@bigteejay
Copy link
Author

@sunjoong - Yes, a different issue.

With the default conf files, I can ping/browse/etc anything not internally hosted on employers network. When connected to VPN, I can't connect to anything (though Windows itself continues to work just fine.)

Changing the order of the entries, removing the auto-gen line, and leaving it with VPN DNS listed first resolves the problem no matter if I am connected to VPN or not.

Not an issue of local domain/search (that works fine with the edited conf file.) I was initially looking to hit a private/internal/VPN-only resource and can only do so with the edited resolv.conf file (without issues at that point.)

@sunilmut
Copy link
Member

@bigteejay - Thanks for your post and sorry for the delay. What you are running into essentially looks like #1350 (or at least it is the same root cause). In Creators Update build, we did some work to identify VPN's DNS entry and made it the first entry in /etc/resolv.conf. But, unfortunately, that was not a complete solution because in some cases we could not identify the VPN's DNS entry (some VPN software do not expose that information). So the fix is also not complete. We are looking to solve this in a more complete way. We do apologize for the inconvenience.

Regarding your question >> should the system not continue to work its way down if upper entries fail?
My understanding is that that happens only if the first DNS server times out (or not reachable). If the first DNS entry is alive and responding, the list is not walked.

@bigteejay
Copy link
Author

@sunilmut - I am using the Creators Update version, and while it is able to retrieve VPN DNS info, it is appending it to the bottom. It doesn't sound like that is the expected behavior? If it was functioning as you described, it would be a non-issue and work perfectly (since appending it to the top was what I did to get it working.)

Regarding the question (and your answer) ah, that makes sense I suppose (unfortunately). I would hope that if the first responded and wasn't able to answer, that it would then try the remaining (which would also solve my problem.) Thanks for the heads up!

@sunilmut
Copy link
Member

@bigteejay - >> It doesn't sound like that is the expected behavior?
It is the expected behavior with the current implementation. As I mentioned earlier, WSL is not able to identify VPN DNS entry in all cases (i.e It works for some VPN software, and for others that information is obscured from us). So, WSL cannot differentiate between the different DNS entries it gets from Windows, for some VPN software. And, unfortunately, your VPN software is in that bucket. That's why I mentioned earlier that it's "not a complete solution". We are looking into this as a whole and we understand the pain that this is causing you and others. For now, I am marking this as duplicate (of #1350) and closing out. Let me know if you feel otherwise.

@sunilmut
Copy link
Member

Just some additional information, in case you are curious. Currently, the way DNS entries are populated in /etc/resolv.conf in WSL is that WSL gets the list of DNS entries during startup (and while bash is running) from Windows. It then populates that list in the /etc/resolv.conf.

@bigteejay bigteejay changed the title VNP still problematic VPN still problematic May 12, 2017
@bigteejay
Copy link
Author

lol, how many times have I read this and only just now the VNP typo in the title (now fixed) :-)

@bigteejay
Copy link
Author

@sunilmut - I must be misunderstanding you. WSL is able to get my DNS info, which is how it got appended to the /etc/resolv.conf file to begin with! This means it is certainly not a duplicate, correct?

It is, in fact, getting the DNS. The DNS is being added to the bottom. Placed there, it does not function. Placed at the top (as indicated in my original post) it works just fine.

@sunilmut
Copy link
Member

@bigteejay - I have also removed the "fixedincreatorsupdate" tag from #1350.

This means it is certainly not a duplicate, correct?
No, its not a duplicate. And, yes, when you add a VPN a new DNS entry gets added to Windows. WSL gets notified of that and we add it to /etc/resolv.conf. For DNS to work in WSL, VPN entry needs to be the first one in the list (placing at the bottom does not work as you have also noted). The solution that we had in CU is to put that DNS entry of the VPN at the top. But, as the problem appears to be is that that (and we knew that going into CU), WSL cannot uniquely identify (or differentiate) the VPN's DNS entry with others, for some VPN software. So, it ends up at the bottom or where it is destined to by luck. Does that make it clear? If not, I will try to go deeper.

@bigteejay
Copy link
Author

@sunilmut - So, in spite of WSL being able to get my VPN DNS, and add it to resolv.conf, it is somehow unable to prepend (rather than append) it?

@sunilmut
Copy link
Member

Exactly, because it does not know which one of the various DNS entries that it gets from Windows, belongs to the VPN. As noted above, for some VPN software, WSL is able to differentiate, for some, it is not. Unfortunately, for yours, it is not.

@bigteejay
Copy link
Author

Gotcha, understood. Thanks for clarifying that for me. Well, at least I have a workaround for in the meantime.

@dannyk81
Copy link

dannyk81 commented Mar 2, 2018 •
edited

If anyone's interested, I was struggling with this issue for a while and was able to find a solution.

I'm connected to multiple vpns, each has it's own dns server and manages different domains. This means that everytime I had to connect to hosts in diffrenet vpns I had to changes /etc/resolv.conf, since name resolution in linux will not try another nameserver (in resolv.conf) if the first nameserver returned an NXDOMAIN (i.e. non-existent domain).

Here's my solution:

  1. Download and install Deadwood DNS for windows (http://maradns.samiam.org/deadwood/)
  2. Install it and configure the following (the rest I kept default):
upstream_servers = {}
upstream_servers["foo.io."]="<dns1 ip>"
upstream_servers["bar.int."]="<dns2 ip>"
upstream_servers["."]="8.8.8.8, 8.8.4.4" # Servers we connect to
recursive_acl = "0.0.0.0/0"
filter_rfc1918 = 0

Replace the domains (foo.io, bar.int) with your requirements (or add more if needed) and set the dns IP that will resolve each.

Note: I had to manually Disable and Stop the Internet Connection Sharing (ICS) service as it is binding to port 53.

  1. Restart deadwood service
  2. Configure this in your wsl /etc/resolv.conf
nameserver 127.0.0.1
search <list-of-your-domains>

enjoy 😄

I realize this is a bit of blog post... but figured anyone who'll stumble upon this may enjoy this hack.

This was referenced Apr 1, 2018
Closed
Open
@donaldpipowitch
Copy link

We tried your workaround today, @dannyk81 , but sadly it doesn't seem to work for us. We could not ping our internal sites and the external sites, just one or the other. I think we did the same you did (e.g. followed all steps correctly).

@dannyk81
Copy link

dannyk81 commented Apr 30, 2018 •
edited

Hey @donaldpipowitch, could you clarify the issue? are you able to ping IP addresses from the two VPN domains without this hack?

When you say ping fails, are you using IP or Names?

can you share your setup details?

@donaldpipowitch
Copy link

Hmm, well in my /etc/resolv.conf I either have nameserver 8.8.8.8 for external sites (so ping google.com works) or nameserver x.x.x.x for internal sites (so ping private.lan works). It only works on or the other, but not both. We downloaded and installed deadwood, configured it (basically just your config, but with upstream_servers["private.lan."]="x.x.x.x", disabled and stopped ICS and started deadwood, but even inside CMD (not the WSL) we only got nslookup google.com 127.0.0.1 to work, but not nslookup private.lan 127.0.0.1.

(Sorry, if I got something wrong. I'm not a big network expert.)

@dannyk81
Copy link

ok, so your /etc/resolv.conf should only have nameserver 127.0.0.1 since you want to send all the queries through deadwood resolver and it will decide where to send the query (based on your upstream configuration), if you can share the whole config with me, perhaps I can help hunt down the issue.

Also, make sure you restart deadwood when you change the configuration (dwood3rc.txt), like so:

C:\WINDOWS\system32>net stop deadwood
The Deadwood DNS cache http://maradns.org/deadwood service is stopping.
The Deadwood DNS cache http://maradns.org/deadwood service was stopped successfully.


C:\WINDOWS\system32>net start deadwood
The Deadwood DNS cache http://maradns.org/deadwood service is starting.
The Deadwood DNS cache http://maradns.org/deadwood service was started successfully.

@Jikodis
Copy link

Jikodis commented Jun 16, 2018

@dannyk81 , I am also having issues getting this to work. I installed the Deadwood service. I disabled network sharing. I stopped and started the service. I think my config files are correct. I will need to resort to simply puting my VPN DNS address at the top of resolv.conf until I can get another solution working. Please look into this Microsoft! You now own Github so it only makes sense.

Here is my Deadwood config file with identifying URLs and DNS addresses made generic:

# Lines with a '#' at the beginning are comments ignored by Deadwood's
# text file parser.

# If you wish to use this program to cache from other recursive servers
# instead of doing its own recursion, uncomment the following lines
#
# Please note that each upstream_servers entry takes up space in Deadwood's
# cache and that maximum_cache_elements will need to be increased to store
# a large number of these entries.
#upstream_servers = {}
#upstream_servers["."]="8.8.8.8, 8.8.4.4" # Servers we connect to

# It is also possible to use other root servers or to blacklist
# a phising website.  However, to do this, root_servers needs to be
# defined.  For example, to blacklist the domain "phish.example.com":
#root_servers = {}
# ICANN DNS root servers (Deadwood default if both root_servers and 
# upstream_servers are not defined)
#root_servers["."]="198.41.0.4, 199.9.14.201, 192.33.4.12, 199.7.91.13,"
#root_servers["."]+="192.203.230.10, 192.5.5.241, 192.112.36.4, "
#root_servers["."]+="198.97.190.53, 192.36.148.17, 192.58.128.30, "
#root_servers["."]+="193.0.14.129, 199.7.83.42, 202.12.27.33"
#root_servers["phish.example.com."]="10.254.254.254"
# Please note that each root_servers entry takes up space in Deadwood's
# cache and that maximum_cache_elements will need to be increased to store
# a large number of these entries.

# The IP this program has 
bind_address="127.0.0.1"

# The IPs allowed to connect and use the cache
recursive_acl = "0.0.0.0/0"

# The file containing a hard-to-guess secret
random_seed_file = "secret.txt" 

# This is the file Deadwood uses to read the cache to and from disk
cache_file = "dw_cache_bin"

# This is a list of IPs that, if we get them in a DNS reply, we convert
# the reply in to a "not there" answer.  
#ip_blacklist = "10.222.33.44, 10.222.3.55"

# By default, for security reasons, Deadwood does not allow IPs in the
# 192.168.x.x, 172.[16-31].x.x, 10.x.x.x, 127.x.x.x, 169.254.x.x,
# 224.x.x.x, or 0.0.x.x range.  If using Deadwood to resolve names
# on an internal network, uncomment the following line:
#filter_rfc1918 = 0

upstream_servers = {}
upstream_servers["mysite.internaldomain.com."]="11.111.111.111"
upstream_servers["anothersite.otherinternal.io."]="11.111.111.111"
upstream_servers["."]="8.8.8.8" # Use Google for other stuff

Here is my /etc/resolv.conf file:

nameserver 127.0.0.1
search mysite.local mysite.internaldomain.com anothersite.otherinternal.io

@dannyk81
Copy link

@Jikodis you should uncomment filter_rfc1918 = 0

# By default, for security reasons, Deadwood does not allow IPs in the
# 192.168.x.x, 172.[16-31].x.x, 10.x.x.x, 127.x.x.x, 169.254.x.x,
# 224.x.x.x, or 0.0.x.x range.  If using Deadwood to resolve names
# on an internal network, uncomment the following line:
#filter_rfc1918 = 0

@Jikodis
Copy link

Jikodis commented Jun 19, 2018

@dannyk81 I appreciate the assistance. I am still experiencing issues after the change. I believe I will step away from WSL until some of these major issues are fixed.

@dannyk81
Copy link

Well, it's up to you :)

I'm using the above setup for ~4 months now and I'm very happy, I have 3-4 VPN tunnels connected all the time and everything works very well.

@Jikodis
Copy link

Jikodis commented Jun 19, 2018

@dannyk81 Okay, I jumped on some other solutions like CYGWIN and was disappointed with the result. Do you know why I might still be experiencing issues getting the Deadwood solution working? Here is my updated dwood3rc.txt file. I removed unnecessary comments. I would love to get this to work.

# The IP this program has 
bind_address="127.0.0.1"

# The IPs allowed to connect and use the cache
recursive_acl = "0.0.0.0/0"

# The file containing a hard-to-guess secret
random_seed_file = "secret.txt" 

# This is the file Deadwood uses to read the cache to and from disk
cache_file = "dw_cache_bin"

# By default, for security reasons, Deadwood does not allow IPs in the
# 192.168.x.x, 172.[16-31].x.x, 10.x.x.x, 127.x.x.x, 169.254.x.x,
# 224.x.x.x, or 0.0.x.x range.  If using Deadwood to resolve names
# on an internal network, uncomment the following line:
filter_rfc1918 = 0

upstream_servers = {}
upstream_servers["mysite.internaldomain.com."]="11.111.111.111, 11.111.111.112"
upstream_servers["othersite.otherinternal.io."]="11.111.111.111, 11.111.111.112"
upstream_servers["."]="8.8.8.8, 8.8.4.4" # Use Google for other stuff

@dannyk81
Copy link

dannyk81 commented Jun 20, 2018 •
edited

Hi @Jikodis

Your configuration looks OK to me, I can't see any reason why this doesn't work.

few things to try/test/verify:

  1. make sure you restart deadwood after changing configuration
  2. set the verbose_level to a high number and see if there's anything relevant in the log
  3. I assume that when querying 11.111.111.111 or 11.111.111.112 directly you get the expected result?
  4. I would try and capture traffic with wireshark... perhaps your FW is somehow blocking something?
  5. how about this nslookup google.com 127.0.0.1? do you get a response from google dns?

/EDIT one more thing:
6) though probably not the case, try to stop deadwood and delete the cache file (dw_cache_bin) and start it again

don't have any additional ideas.

@Jikodis
Copy link

Jikodis commented Jun 26, 2018

Hello @dannyk81
Thanks for the assistance. I have restarted deadwood. verbose_level is set at 100 and I did not see anything useful in the logs. I cleared out the cache file in the Deadwood directory. When I do an nslookup of my internal domains, I get the respective DNSs I expect. I did have a DNS set on my router as well as a rule to enforce them, but I have since taken those off. I am still having issues even after resetting the router and computer.

Below is the result of running nslookup google.com 127.0.0.1 on Windows and WSL:

C:\Users\myusername>nslookup google.com 127.0.0.1
Server:  UnKnown
Address:  127.0.0.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:400a:800::200e
          216.58.193.78


C:\Users\abush>wsl
--- Users/myusername » nslookup.exe google.com 127.0.0.1
Non-authoritative answer:
Server:  UnKnown
Address:  127.0.0.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
Name:    google.com
Addresses:  2607:f8b0:400a:800::200e
          216.58.193.78

@dannyk81
Copy link

dannyk81 commented Jun 27, 2018 via email •
edited

@Jikodis
Copy link

Jikodis commented Jun 27, 2018

This is what I get in the log:

June 26, 2018 20:32:10 PM: Got DNS query for \006google\003com\000\000\001
Tuesday, June 26, 2018 20:32:10 PM: Looking in cache for query \006google\003com\000\000\001
Tuesday, June 26, 2018 20:32:10 PM: Nothing found for \006google\003com\000\000\001
Tuesday, June 26, 2018 20:32:10 PM: Caching direct answer at \006google\003com\000\000\001
Tuesday, June 26, 2018 20:32:10 PM: Looking in cache for query \006google\003com\000\000\001
Tuesday, June 26, 2018 20:32:10 PM: Fetching \006google\003com\000\000\001 from cache
Tuesday, June 26, 2018 20:32:10 PM: Got DNS query for \006google\003com\000\000\034
Tuesday, June 26, 2018 20:32:10 PM: Looking in cache for query \006google\003com\000\000\034
Tuesday, June 26, 2018 20:32:10 PM: Nothing found for \006google\003com\000\000\034
Tuesday, June 26, 2018 20:32:10 PM: Caching direct answer at \006google\003com\000\000\034
Tuesday, June 26, 2018 20:32:10 PM: Looking in cache for query \006google\003com\000\000\034
Tuesday, June 26, 2018 20:32:10 PM: Fetching \006google\003com\000\000\034 from cache

When I run netstat -anp | find ":53" in the command window whether Deadwood is running or not, I get nothing returned. That leads me to believe no service is using port 53. I tried using TCPView (https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview) and did not see port 53 showing up anywhere. I tried all this with and without my Cisco AnyConnect VPN running.

@rfgamaral
Copy link

I also have the same problem as above, can't get Deadwood to work for me.

@Mortinke
Copy link

For my site, Deadwood + Cisco AnyConnect VPN + WSL works well.

@dannyk81
Copy link

@Jikodis this is curious, Deadwood should listen on port 53 when it's running... I'm not sure why, but this is where I would focus.

@nivekastoreth
Copy link

Just leaving a note here that I've gotten deadwood working, just not in conjunction with my Cisco AnyConnect VPN client. As soon as I connect, all requests that were previously going to deadwood are no longer received by it, resulting in timeouts. As soon as I disconnect, it begins working as expected. So far I've had no luck in finding a workaround for this.

Cisco AnyConnect 4.6.01098 
Microsoft Windows 10 Pro 10.0.17134 Build 17134
Deadwood 3.2.11-win32

@sc-moonlight
Copy link

@nivekastoreth Checkout https://docs.microsoft.com/en-us/windows/wsl/troubleshooting "Bash loses network connectivity once connected to a VPN"

@nivekastoreth
Copy link

nivekastoreth commented Aug 5, 2018 •
edited

@sc-moonlight thanks for the link, but I currently have aliases to do the swapping of the resolv.conf file for me (as that document suggests), but was attempting to replace that strategy because it's annoying and seems to not be effective 100% of the time. My previous comment was just to serve as an additional note for anyone else, who finds there way here, to weigh whether or not they also wish attempt to go down the deadwood/local dns proxy, especially if they're also using anyconnect and/or see if anyone has previously solved the issue I ran into.

The real answer is that #1350 just needs to be fixed, then all these hacks can be done away with.

@nbelakovski
Copy link

FWIW, I solved this problem by ssh'ing into a machine inside the VPN with Putty, noting its /etc/resolv.conf configuration, and basically combining my local file with the one from the machine inside the VPN

@mr-deamon
Copy link

@sc-moonlight thanks for the link, but I currently have aliases to do the swapping of the resolv.conf file for me (as that document suggests), but was attempting to replace that strategy because it's annoying and seems to not be effective 100% of the time. My previous comment was just to serve as an additional note for anyone else, who finds there way here, to weigh whether or not they also wish attempt to go down the deadwood/local dns proxy, especially if they're also using anyconnect and/or see if anyone has previously solved the issue I ran into.

The real answer is that #1350 just needs to be fixed, then all these hacks can be done away with.

Did you solve that @nivekastoreth ?

@nivekastoreth
Copy link

nivekastoreth commented Dec 6, 2018 •
edited

@mr-deamon a little late responding, but no. I've spent many hours attempting to figure this out, and I still don't know what it was between Windows, Deadwood, WSL and my Cisco VPN that made the setup not work

I have given up and just accepted that I'll be using cygwin for the next year or two until the issues I have with WSL are resolved.

(Edit: the final straw for me was #2913 which requires me to reboot my entire computer in order to get networking inside of WSL working again. After that I just threw in the towel)

@mr-deamon
Copy link

@nivekastoreth We "fixed" it by using a (very old) VPN-client called shrew-vpn. This one does not mess with DNS

@therealkenc therealkenc mentioned this issue Dec 8, 2018
Closed
@therealkenc therealkenc mentioned this issue Mar 16, 2019
Closed
@gcollombet
Copy link

For me it was due to IPv6 problem : #2142

@max-cool
Copy link

Sorry to revive this, but I have a solution to this that I haven't seen documented for Cisco AnyConnect users. For WSL users on VPN who can only resolve internal (and not external) domains with their company's internal DNS, I found out this was caused by AnyConnect split tunneling VPN traffic.

This can be changed by adding /TUNNELALL to the VPN url, which will have AnyConnect do full tunneling. The profiles are usually defined in xml files in "%PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile", so you can change the url there.

Hope this helps people searching this issue from google like myself.

@paulvasquez
Copy link

I am on Windows 10 with WSL version 1 and Ubuntu 20.04LTS. Worked perfectly. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
network
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests