This message was deleted.
# rancher-desktop
This message was deleted.
Hi @nice-toddler-37804, thank you for reaching out. The new networking stack is being implemented by @calm-sugar-3169 (with some help from @proud-jewelry-46860). It is basically based on
and the logic from
. I've seen a demo of the proof-of-concept about a week ago, and it looks extremely promising. So much so actually that we'll make this code available as an experimental feature in the next release. You can see the full epic for it at Epic: Incorporate gvisor into Rancher Desktop's networking stack · Issue #3810 · rancher-sandbox/rancher-desktop (we plan to move to a similar networking stack for all platforms, but the initial code is for WSL only). I think this should solve the existing issues around VPN support on Windows, but I think it will need additional work to support proxies. I'm sure Nino will reach out to you to figure out how you can work together on this. It will likely have to wait for the following release though, as we are already pushing out our original intended release date for 1.8 to wrap up the planned features and the new experimental gvisor work.
Note that the new networking stack for WSL also includes setting up a dedicated network namespace for Rancher Desktop, which will help keeping iptables rules isolated to RD and not affecting other WSL2 distros.
Thanks @fast-garage-66093, yes let me know how I can help. I guess there will be some work to integrate gvisor port forwarding with the port forwarding function of rd for instance. I've already started looking at the code of the PoC. I will try it on my local rancher-desktop build in the meantime.
yup proxy and vpn route issues are usually independent. no route will obviously impact proxy access so they are intertwined, but the solutions will different changes. docker’s fix was to use a distro proxy and handle all the forward and direct logic in that. it feels like intra-cluster traffic for k3s could be handled with no_proxy and hostname based connections, but it’s complicated and I have not figured out a good method of making it work in all my attempts.
@nice-toddler-37804 welcome back simple smile and thanks for actually getting this done! I had a chance to briefly take a look at it and it looks promising, I will take a more thorough look and will provide you with some feedback shortly. As for the UI changes it would need a deeper discussion with the UI team on how it will fit into the existing UI scheme but we can discuss that later. As for the new
based networking approach I should have a working experimental version shortly (in 1.8 release) which will allow you to run your changes on top of the new networking stack. The new changes will isolate the Rancher Desktop network namespace from the rest of the WSL VM with one major goal of migrating the existing rancher desktop services and processes to the new network namespace with minimum possible effort. So, I think your changes should just work right out of the box if it’s currently being started correctly by the
@wide-mechanic-33041 I know you have been battling with proxy on Rancher Desktop for quite some time to get certain things to work. Are you able to provide a list of acceptance criteria/ features (your expectation from the new proxy approach) that will satisfy your requirements? The reason being I just want to make sure we have some of those features covered. Thanks simple smile
just that i can set a proxy (using the system provided PAC is ideal, but not critical path) and that both docker and k3s work as expected. my issue has been k3s since I can’t exclude a CIDR in no_proxy so internal cluster flows start failing since they hit our proxy. not even sure the vpnkit isolation will allow for excluding the right network space. if the team has a wireframe in github I should be able to think it through for my situation. we also have some destinations behind a forced auth via 407 which may or may not cause issues depending on how the CONNECT is handled.
@calm-sugar-3169 There are still some minor changes required the interface in the
window does not fit really well. I also need to support
but right now I don't get any error from k3s like I previously did when using rancher-desktop with the proxy sets in
(905). I think that's the one @wide-mechanic-33041 used to have ? Perfect I will wait for the 1.8 release to test the if both changes get along nicely. Maybe I'm missing something but if the traffic of the WSL VM is sent to the host daemon used as a gateway, shouldn't the system proxy settings just be applied to that host daemon? Which makes my change not required anymore.
This is the actual interface change.
@nice-toddler-37804 One thing we need to consider for the UI is that we will want the same experience on macOS and Linux too, so maybe the settings need to live outside the WSL integration page, but I don't know that yet
Please attach your UI change screenshot to the Github issue, so we can bring this up in a UI sync meeting
yeah WSLENV was the way I could get the proxy into the distro (though wouldn’t work for a RD only setting since that applies to all distros). putting a forward proxy in the distro definitely could fix k3s flows from trying to use the external proxy for its internal traffic since intra-distro should just use moproxy and moproxy will send flows upstream or swing them back if they are for the local network.
@fast-garage-66093 Sure, right now I just added it to the "WSL" section since I only tested the change there. I can't test it but I think it should work similarly in MacOS. Which Github issue ? 3810 ? Do you want me to do a pull request so you can discuss it there maybe ?
@nice-toddler-37804 Sorry, I was confused: I somehow thought you had created a Github issue about your proxy work, and I wanted you to attach it there 😄 Maybe create a new issue now. Nino is heads-down working on the gvisor feature to make it possible to include it as an experimental setting in the 1.8 release, so probably not much discussion about proxies is going to happen until we are ready to ship that.
Thank you!
@nice-toddler-37804 the nested scrollbars in the UI screen shot are painful. Can you please set the innermost item not to have scrollbars and rely on the outer container's scrollbars?
@quick-keyboard-83126 Fixed and added the
window modal on the github issue. The issue with the double scroll bar is coming from the
button on the bottom right of the
. What do you think about those changes. I can make a PR to propose those changes.
Copy code
diff --git a/pkg/rancher-desktop/components/Preferences/ModalBody.vue b/pkg/rancher-desktop/components/Preferences/ModalBody.vue
index 42082b33..93b48094 100644
--- a/pkg/rancher-desktop/components/Preferences/ModalBody.vue
+++ b/pkg/rancher-desktop/components/Preferences/ModalBody.vue
@@ -58,11 +58,14 @@ export default Vue.extend({

 <style lang="scss" scoped>
   .preferences-body {
+    position: relative;
     display: flex;
     flex-direction: column;

     .help {
-      margin: auto 0.75rem 0.75rem auto;
+      position: absolute;
+      bottom: 1rem;
+      right: 1rem;
Seems good to me