Users may be unable to connect to Live Share services via a proxy

[jasongin]

Users who are on a network that requires use of a proxy server to connect to external websites may experience problems using Live Share. Specifically, attempting to share using a connection mode of Auto (the default mode) or Relay may fail to connect to the relay service.

A partial workaround may be to use Direct connection mode, however then guests must be on the same network as you in order to join the session. (Direct connections may also work through a VPN, depending on the VPN client and server configuration.)

Please upvote and/or comment on this issue if you're experiencing proxy-related issues.

[binaryn3xus]

Just for anyone else working on this issue. The problem that I experiences with this issue went all the way down to only working on the same LAN connection. VPN over a WAN connection or anything like that would not work for me through our company proxy.

[Chuxel]

Note we added a section on troubleshooting connections based on our experiences here to the docs to try to help people out. https://github.com/MicrosoftDocs/live-share/blob/master/docs/getting-started.md#troubleshooting-connections

[jasongin]

@Chuxel that looks great! The "getting started" page is getting really long though. Do you think it would make sense to move the sections about connection mode, connection troubleshooting, and firewall settings to a separate page, linked from the getting started page?

[Chuxel]

@jasongin Yeah I was thinking about that as well. There's also the quick start articles that cut to the chase so this is the more detailed article with things like manual join in it so we'll have to figure out the right balance for this one.

[Chuxel]

@jasongin We also had a user on Slack mention that we are not respecting the VS Code proxy settings. My assumption is we'll track this problem with this same GitHub issue.

[kdruff-c1]

Our proxy essentially serves as a MITM and I'm seeing this issue when trying to sign-in:

fetch('https://insiders.liveshare.vsengsaas.visualstudio.com/').then(res => res.json()).then(console.log);

The promise is rejected and my fetch fails:

GET https://insiders.liveshare.vsengsaas.visualstudio.com/ net::ERR_INSECURE_RESPONSE

[Chuxel]

@kdruff-c1 It looks like this is indeed a specific issue with proxies that we've now identified. We've got an internal thread going to see what we can do about it in the service. Thank you so much for reporting it!

[Chuxel]

The intermediate SSL cert issue (#111) that was at least partially responsible for causing this issue should be resolved at this point. @kdruff-c1 - Can you retry to see if it resolves your problem? @JoshuaGarrison27 - I'd be curious if your issue is resolved as well. We're still working on full proxy support.

[Chuxel]

@jasongin FYI - Joshua and I connected and he's still seeing the problem so we'll leave this issue open for the larger proxy problem.

[binaryn3xus]

Just for logging purposes, I worked with Chuck (@Chuxel ) to see if this was resolved for me. It looks like I will have to wait for full proxy support. Thanks for keeping me in the loop!

Edit: Should have refreshed my browser before posting this. haha. Thanks everyone.

[kedruff]

I am unable to install dependencies ...

Visual Studio Live Share was unable to download needed dependencies to finish installation. Ensure you have network connectivity and restart VS Code to retry.

Sorry for the account change from @kdruff-c1 ... one of my colleagues had success creating a new github account w/ his corporate email and I tried that to no avail...

[Chuxel]

@kendruff The good news is we're past the SSL issue, the bad news is it sounds like you may have some needed locations blocked by your local or corporate firewalls - least when not going through the proxy. Try running these commands from a terminal (you can also grab curl for windows here):

curl https://download.visualstudio.microsoft.com
curl https://download.microsoft.com

...and then...

curl --noproxy "*" https://download.visualstudio.microsoft.com
curl --noproxy "*" https://download.microsoft.com

If the first two give you a "document moved" HTML snippet while the last two cannot reach the destination, you're now hitting the proxy problem we have not resolved yet. Am I correct in assuming that is the case?

As an aside, there was a circumstance where GitHub accounts were unable to start sharing (see #99) but this should be resolved. This error is prior to that point so it likely is not related.

[ericc4]

Is there additional troubleshooting that I could add as a user to help with getting proxy connectivity working?

Forgot to add: Windows 7, VScode 1.20.1, authenticated corporate proxy that I unfortunately do not control

[Chuxel]

@ericc4 Depending on your situation and the exact error you are seeing, we may need to implement better proxy support before you are unblocked. That is entirely dependent on the error you are getting, however.

That said, what error are you seeing and at what point?

[ericc4]

@Chuxel When I sign in I get "Error Login Failed" from VScode, but in the browser it says "Ready to collaborate". I've tried entering a user code but I get the same error from VScode. Everything else in VScode that would require the proxy works fine, such as updates and installing extensions

[Chuxel]

@ericc4 This may be due to the bug this issue is tracking. However, to verify, can you send us your logs after reproing? You can run the "Live Share: Export Logs" command to get a zip. From there you can either attach it here or shoot it to us at vsls-feedback@microsoft.com. @jasongin and I can verify its the same problem.

[AjkayAlan]

#120 is a variation to this except it seems like it is stopping the sign in instead of stopping a sharing session. I closed #120 so we can focus on this first, and I will reopen it if this is fixed and #120 is not.

[Chuxel]

For other's info - Both ericc4 and AjkayAlan had the following telltale sign in their logs that are another indicator of this problem:

[2018-03-01 16:35:16.603 Agent.Http E] > POST https://insiders.liveshare.vsengsaas.visualstudio.com/auth/token (c150ms sms) => 407 Proxy Authentication Required

[zachberger]

I suspect there is also proxy issue when installing. I get stuck with this for about a minute:

Followed by:

curl https://download.visualstudio.microsoft.com
curl https://download.microsoft.com

outputs HTML

curl --noproxy "*" https://download.visualstudio.microsoft.com
curl --noproxy "*" https://download.microsoft.com

outputs
curl: (7) Failed to connect to download.visualstudio.microsoft.com port 443: Timed out

At this point I don't see Live Share: Export Logs in the command palate. I'm able to install other extensions with no issue.

[Chuxel]

@zachberger Thanks for the awesome data. You are indeed correct. We cover this in connectivity troubleshooting, but here's the breakdown:

1. Finishing the installation (as you see above) for VS Code requires access to download.visualstudio.microsoft.com and download.microsoft.com
2. Signing in requires access to *.liveshare.vsengsaas.visualstudio.com (specifically insiders.liveshare.vsengsaas.visualstudio.com right now)
3. Running in "relay" mode requires access to *.servicebus.windows.net

Each of these may be impacted by this proxy issue depending on the exact rules your company has setup.

[jasongin]

@zachberger, do you have HTTP_PROXY / HTTPS_PROXY environment variables set on your system? It's likely the Live Share extension isn't using them, but should.

Unfortunately VS Code doesn't do anything to help extensions use the correct proxy settings. For some discussion on that topic see microsoft/vscode#12588

We know there are a few things we need to do to fix proxy issues for Live Share; it's just taking some time to investigate, develop, and test the fixes.

[zachberger]

Thanks, setting the proxy environment variables fixed. Normally I depend on my .bash_profile to do this, but when clicking a join link it didn't open VS Code via bash. I've now set them the variables system wide and the installation and sign in completed.

[Chuxel]

@ericc4 @AjkayAlan @kedruff @JoshuaGarrison27 I had another person confirm that setting the environment variables Jason mentions above resolved the issue for them.

Do any of you have HTTP_PROXY and HTTPS_PROXY environment variables set globally? If not, can you set these and retry?

[jasongin]

@Chuxel, those variables apply to Mac OS (and Linux, when we support it later). I don’t think they will help with any proxy issues on Windows.

However the latest Live Share update, released yesterday for VS Code and soon for VS, includes a fix specifically for authenticating proxies on Windows.

[Priya91]

@k7shanmugam @jasongin @srivatsn People are hitting downloader issues on vscode due to cert issues, and as mentioned here, these are already solved by vscode, we should push to get the downloader apis exposed, so we don't have to duplicate these solutions in our extension as well.

[jakauppila]

I was able to get past Dependency download failed. RequestError: unable to verify the first certificate by specify the environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0.

Far from ideal, but it does pinpoint that the issue is that node is not looking at the appropriate trust stores.

[lostintangent]

We've made a significant amount of improvements to our proxy support (thanks @Priya91!), so we're going to close this general-purpose issue, and track any remaining proxy work via specific issues. Please let us know if you run into connectivity problems. Otherwise, we'll track progress via the issues we've already got logged. Thanks!

[lornz]

Is there a solution for proxies with a 'pac'-File?

"Unable to connect to the remote server. TrackingId:40b15f09-60d4-4c48-a8ee-76eb4d25e532, Address:sb://vsls-prod-ins-euw-private-relay.servicebus.windows.net/c0b214cbd3852b83c1535c97274f182be2b4--70c9e139-ed6f-485c-bf1b-5f0ef2ff7eb1, Timestamp:15.08.2018 07:48:27"

[grork]

@Priya91, do you have any insight into PAC files?

[yangwen2]

@lornz For pac file, have you tried to set the proxy setting to one of the server + port specified in your PAC file?

[Jeff5519]

Our internet access requires a proxy server with user authentication.

The method of setting http_proxy and https_proxy for Visual Studio Live Share is a very poor design since it exposes a user name and password into a system wide environment variable.

Is there any plan for a more secure method of dealing with a proxy server?

[Priya91]

@Jeff5519 If you use your AAD logon credentials for proxy authentication, and you have the proxy setting configured in OS Settings, then we will read the proxy information from OS and use your logon credentials to authenticate. If you need separate credentials, we don't support that today, since that requires having a separate UI to get the credentials from user, and then securing it.. We haven't had many user reports for this scenario, so we don't have plans to support that yet.

[farangkao]

Tried several ways to connect in Visual Studio 2019, but i don't manage to connect by Relay or Direct.
Behind Firewall (with Proxy Pac configuration)
I can download and read the proxy pac file and i also tried to use some of the ip addresses there for stearing via HTTP_PROXY and HTTPS_PROXY, but to no avail.
The Output from Live Share Window stays empty, the Message on Top says can't connect.

Our proxy does use Active Directory logon credentials and the Proxy settings are configured in the Windows 10 Proxy "script" section.

[Priya91]

@farangkao Use the connectivity troubleshooting tips here: https://docs.microsoft.com/en-us/visualstudio/liveshare/troubleshooting#connectivity

[Jeff5519]

I was able to get live share working by setting the HTTP_Proxy and HTTPS_Proxy environment variables without including my logon credentials.
HTTPS_PROXY=http://:8080
HTTP_PROXY=http://:8080
Some things that may have helped: Make sure you create these as system environment variables and reboot after you set them. Both definitions use "http".

[yilun11]

It doesn't seem to respect http proxy variables in JSON config file, but will respect them in environment variables (Windows, 1.37.1). Unfortunately, those env variables will interfere with other apps trying to access local network so I'll see if I can get it to respect it somehow from JSON config.

[michael-buchner]

Works perfectly with system env variables but we don't want to deploy them globally. Any other way to make it work with proxy? Why is Live Share not able to read proxy settings from OS?

[kpatrick]

curl https://download.visualstudio.microsoft.com currently gives back an error

<title>500 - Internal Server Error</title>

500 - Internal Server Error

[michael-buchner]

curl https://download.visualstudio.microsoft.com currently gives back an error

<title>500 - Internal Server Error</title> # 500 - Internal Server Error

It is https://visualstudio.microsoft.com/downloads/

[hjrb]

In our environment it still doesn't work in sudden cases. For extensions it work. But for LiveShare it doesn't. The only way to get this to work is to set both environment variables AND set the property "http.proxy" in the settings.json to the address of the proxy server including the user name and password. That is certainly a security issue and very inconvenient.

[Maxim-Mazurok]

We have two proxies:

1. The one that uses NTLM Authentication (using Windows credentials, Active Directory, all that stuff)
2. And we have proxy without any auth, specifically for tools such as git/npm/etc that do not support NTLM Auth.

When I set HTTP_PROXY and HTTPS_PROXY to proxy #1 (NTLM auth) - it doesn't work, logs me out and doesn't let me log in with my Microsoft account, redirects to http://127.0.0.1:53612/?error=Unable%20to%20login.

When I set these env vars to proxy #2 (no auth) - it works like a charm. Logs me in and lets me use live share session.

So, am I correct to assume that this extension doesn't support NTLM Auth proxies?

[Maxim-Mazurok]

Also, docs say that it'll use default system proxy on Windows, but it doesn't.
I have my system settings set to auto-detect mode.
And we have wpad.dat file with function FindProxyForURL(url, host) {...} that chooses the right proxy for host.
But I can see in Wireshark that it's trying to connect to vsls servers directly:

[LongLiveCHIEF]

My guess with all these problems is that the Live Share extension tries to re-encode an already url encoded password. So let's say you have a password of p@ssword!. then your proxy would be https://user:p%40ssword%21%0A@proxy.host:<port>.

I think what Live Share does is take that value and re-encodes it to be: https://user:p%2540ssword%2521%250A%0A@proxy.host:<port>

[LongLiveCHIEF]

The other thing I've noticed is that the HTTP(s)_PROXY isn't picked up from the user's environment on both Mac and Windows. I have to explicit launch from the command line in a shell that has the HTTP_PROXY in the shell environment.

[LongLiveCHIEF]

My guess with all these problems is that the Live Share extension tries to re-encode an already url encoded password. So let's say you have a password of p@ssword!. then your proxy would be https://user:p%40ssword%21%0A@proxy.host:.

I think what Live Share does is take that value and re-encodes it to be: https://user:p%2540ssword%2521%250A%0A@proxy.host:

I've done additional testing, and have further evidence to support this theory. There are 4 special characters that are "url safe". If you use a proxy password containing special characters restricted to that set (-_~.), then Live Share (and MS authentication) will be successful through proxy.

Any other characters will require you to encode them in the environment in order to work with every other app out there, and thus, Live Share will re-encode an already encoded password.

The solution for all these problems is for the Live Share extension to stop doing urlencode() on connection strings (or at least the password segment of the string).

I can't confirm this of course because the extension source isn't available.

[LongLiveCHIEF]

Another tidbit... this behavior regarding character encoding seems to be limited to Mac (and I'm assuming Linux)... which makes sense based on the different way VSCode handles proxy settings on Windows vs *nix platforms.

[andrewzagorski]

What servers are required access for live share? https://docs.microsoft.com/en-us/visualstudio/liveshare/reference/connectivity seems outdated as https://insiders.liveshare.vsengsaas.visualstudio.com/ gives a 404. Having 'hanging' problems on mac.

[LongLiveCHIEF]

@andrewzagorski they don't respond to things here. It's been 3 months since I gave them evidence of what is causing all the issues with this, and they haven't so much as reacted with an emoji.

[PilkatipTwink]

well but what to do if i cant dowland vpn on my laptom because it is bloocked