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?

Thanks @echoing-carpenter-38694, Please let us know how your testing goes.

@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

thanks!, I'm just waiting for the windows build to finish here

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 that's what i was seeing

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.

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

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.

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

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

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!

@echoing-carpenter-38694 Which http proxy are you using ?

It's a corporate proxy I don't have a lot of details on. I also don't believe it supports TLS

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

Yes exactly

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

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 😅

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

will test that out shortly

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

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

Do you also use kubernetes ? I think in the past people using this solution had issue running kubernetes but maybe the networkingTunnel fixed this ?

yeah it seems to be fine

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?

@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

Thank you for sharing. Yes, it's quite spammy 🙂. Hopefully they will identify a better approach.

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.