https://rancher.com/ logo
Title
e

echoing-carpenter-38694

05/03/2023, 5:45 PM
Hello all, I'm new to rancher-desktop. I'm working for a corporation that has a mandatory VPN and corporate proxy. I've been having trouble getting rancher-desktop to replace docker-desktop at this point, I'd love to use Rancher especially since we are planning on using k3s when going to prod so hoping to keep development as close to prod as possible. I was originally running into ks3 startup issues, but that has been resolved with 1.8.1 and the experimental gviser network tunnel. I'm now running into timeout issues when doing and docker pull or really any network command from the wsl vm. I was assuming this is proxy related, I tried setting WSLENV for http_proxy and https_proxy but unfortunately our corporate proxy isn't TLS so that again causes k3s to not start. Any other workarounds for this issue?
I see this PR.. But I was under the assumption that the network tunnel would fix proxy issues vs having to configure them in the WSL instance https://github.com/rancher-sandbox/rancher-desktop/pull/4300
Oh sweet, I see someone triggered the package step on that PR, can test it out shortly in that case
r

rapid-eye-50641

05/03/2023, 5:57 PM
Thanks @echoing-carpenter-38694, Please let us know how your testing goes.
n

nice-toddler-37804

05/03/2023, 6:11 PM
@echoing-carpenter-38694 let me know if that work for you (don't hesitate to ping me). I just want to point that right now you should provide the proxy address as an IP address and not a domain name. A fix is waiting to be merged https://github.com/sorz/moproxy/pull/22
👍 1
e

echoing-carpenter-38694

05/03/2023, 6:18 PM
thanks!, I'm just waiting for the windows build to finish here
w

wide-mechanic-33041

05/03/2023, 6:32 PM
yup proxy is very much on the RD teams radar as I know its a big impediment for me as well. Not just for registry stuff, but even for the installs that depend on an external resource where it isn’t a true airgap.
yeah the issue w setting a proxy is doing the no_proxy as well and the use of IP based cluster flows in place. WSL does dynamic election so the cluster IP is a moving target.
e

echoing-carpenter-38694

05/03/2023, 6:35 PM
yeah that's what i was seeing
I'm hoping this PR fixes things, looks like the build is about done
w

wide-mechanic-33041

05/03/2023, 7:17 PM
from comments with the RD folks the 1.9.1 may take a bit longer to release, but the proxy thing is front of mind. but as you see it gets complicated as its a complicated orchestration of forwarding from the rd-distro for certain flows while some stay internal. And all that config management in pref panes and config files.
👍 1
e

echoing-carpenter-38694

05/03/2023, 7:25 PM
Installed the build from that PR.. Initial results is k3s doesn't start. I receive a fatal message "no default routes found in /proc/net/route or /proc/net/ipv6_route" .. This is with the network tunnel enabled but no proxy configured yet
w

wide-mechanic-33041

05/03/2023, 7:33 PM
yeah I think the PR is very much a WIP. the core is solid, but the pattern and integration I am sure is where a heavy amount of work is to be done.
e

echoing-carpenter-38694

05/03/2023, 7:47 PM
yeah the error seems unrelated to the PR for proxy as I haven't even enabled it yet, but could be some other unrelated change still a WIP
looks like the host side of the tunnel is erroring trying to bind to port 80 because it's excluded on my machine. were any changes made there?
or at least host-switch log contains an error about trying to bind to 0.0.0.0:80
n

nice-toddler-37804

05/03/2023, 9:11 PM
@wide-mechanic-33041 Did you have the opportunity to test the proxy PR ? About
NOPROXY
I planned to add the code to support it once this PR get merged.
e

echoing-carpenter-38694

05/04/2023, 1:16 AM
Ok, found out what was locking port 80 after a break had some netsh interface portproxy bindings probably from a prior instance of rancher-desktop. seems it didn't clean up after itself. had to clear those and do a fresh install and all was good. tested out the proxy: getting 403s now on a docker pull due to a certificate name mismatch getting closer!
n

nice-toddler-37804

05/04/2023, 6:46 AM
@echoing-carpenter-38694 Which http proxy are you using ?
e

echoing-carpenter-38694

05/04/2023, 12:01 PM
It's a corporate proxy I don't have a lot of details on. I also don't believe it supports TLS
w

wide-mechanic-33041

05/04/2023, 12:03 PM
yeah commonly the proxy CONNECT statements won’t be tunneled, but the traffic passing through will be. so your proxy will listen for http but has no problem forwarding https
n

nice-toddler-37804

05/04/2023, 12:09 PM
Yes exactly
I've seen a similar issue with "McAfee Web Gateway" typically used in a corporate environment.
e

echoing-carpenter-38694

05/04/2023, 12:40 PM
ah good call, I threw the raw html of the 403 into a file and it does look like it came from a mcafee web gateway
did you find a workaround for that @nice-toddler-37804 ?
n

nice-toddler-37804

05/04/2023, 12:45 PM
Not yet. I don't have access to such proxy myself which make the debugging more complicated of course. I will let you know, any inputs are welcome 😅
w

wide-mechanic-33041

05/04/2023, 12:47 PM
well the cert mismatch probably means you are doing interception so the proxy is a MITM and you will need to hash your internal CA cert with the one in alpine or disable registry trust
if you do an openssl s_client call to www.docker.com as example likely you will see it was signed not by the actual public CA, but by a company.mcafee.com CA (or something like that). And given RD won’t trust that CA you are getting a TLS breakdown.
👍 1
e

echoing-carpenter-38694

05/04/2023, 12:51 PM
will test that out shortly
w

wide-mechanic-33041

05/04/2023, 1:27 PM
you might need to install some apks in the alpine dist. honestly can’t remember, but you can also test this from your host as the PR solution is just forwarding onto the configured upstream proxy. Just look for certificate trust and it will stand out that there is a possible MITM at play
e

echoing-carpenter-38694

05/04/2023, 2:13 PM
from what I can tell it seems rancher desktop already copies local ca certificates over from my host and calls update-ca-certificates from within alpine, so not convinced its a trust issue, i'd assume that would present a different error
Ok forgot to update this thread. What ended up working getting docker pull etc working. I just reverted back to 1.8.1 with the network tunnel enabled in combination with the directions here: https://github.com/rancher-sandbox/rancher-desktop/issues/4289
n

nice-toddler-37804

05/05/2023, 1:27 PM
Do you also use kubernetes ? I think in the past people using this solution had issue running kubernetes but maybe the networkingTunnel fixed this ?
e

echoing-carpenter-38694

05/05/2023, 1:44 PM
yeah it seems to be fine
I previously was getting errors about my non-ssl proxy in k3s, when i was trying to wslenv my HTTPS_PROXY config since it's non tls.. but for whatever reason that is no longer happening with setting them in that file instead
r

rough-balloon-94624

05/12/2023, 3:29 PM
I have been working to also have firewall ports opened up to support Rancher Desktop in a similar environment (the proxy feature will be helpful to us for sure!). I did have a question when I was working with our firewall team as it seems Rancher Desktop is constantly pinging example.com every few seconds. If it cannot, it raises the error saying that general Internet access is not available, so it will not pull/update the k3s list available to it, even though it can get to k3s as we had opened it. Any thoughts on why this check is running every few seconds?
c

calm-sugar-3169

05/15/2023, 6:46 PM
@rough-balloon-94624 I think it’s a simple check to make sure that RD is still connected to the internet or not here: https://github.com/rancher-sandbox/rancher-desktop/blob/f018523a0662743ca2d9f386cb[…]595/pkg/rancher-desktop/main/diagnostics/connectedToInternet.ts
also, looking at this issue: https://github.com/rancher-sandbox/rancher-desktop/issues/4639 it looks like that approach might change since it is a bit spammy.
r

rough-balloon-94624

05/15/2023, 11:16 PM
Thank you for sharing. Yes, it's quite spammy 🙂. Hopefully they will identify a better approach.
w

wide-mechanic-33041

05/16/2023, 12:58 PM
maybe https://learn.microsoft.com/en-us/windows/win32/api/netlistmgr/nf-netlistmgr-inetworklistmanager-getconnectivity is an option? would be platform specific, but may be worth the conditional logic.