This message was deleted.

nope not yet as the kube traffic is also being sent to the proxy most likely, but the proxy can’t send it back to the virtual network. setting no_proxy can help most likely with the network being used by the VM

Yes, we have set no_proxy as well with override.yaml. It still doesn’t work

yeah, i’ve gone through many of them…

yup known that it is a rough spot, but bigger changes will be needed to make it work well

yeah, that’s bummer. With this override.yaml we can use docker and containers, only if Rancher Desktop starts succesfuly:

env:
  http_proxy: "<http://proxy.server>:port"
  https_proxy: "<http://proxy.server>:port"
  no_proxy: "10.0.0.0/8,127.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
provision:
- mode: system
  script: |
    if ! grep -q "^HTTP_PROXY" /etc/conf.d/docker; then
      echo "export HTTP_PROXY=\"<http://proxy.server>:port\"" >> /etc/conf.d/docker
      echo "export HTTPS_PROXY=\"<http://proxy.server>:port\"" >> /etc/conf.d/docker
      echo "export NO_PROXY=\"10.0.0.0/8,127.0.0.0/8,172.16.0.0/12,192.168.0.0/16\"" >> /etc/conf.d/docker
    fi

cidrs don’t work most likely

I’ve tried explicit IPs (without CIDR) as well

i know when i added my cluster ip explicitly things got somewhat better

OK, it worked, let me restart it again. It is hard to reproduce, it stops to start every now and then…

yup thats part of the issue. if the clusterip and calls move to dns than no_proxy should become more reliable

I was beginning to question my sanity while expecting different results over and over again… 🙂

nope thats why i link to the proxy-area tag with all the open issues to show that proxy is a rough road

Thank you, I hope those issues get prioritized, since many other companies probably evaluate Rancher Desktop, because of the licensing costs of Docker Desktop.

^ attention @fast-garage-66093 @rapid-eye-50641