1. Home
  2. Categories
  3. Coding Help
  4. Network access from WSL with ZScaler

Network access from WSL with ZScaler

  • R

    Yeah, I'm full of :fun: ideas like that, but then again for problems of the "normal" kind I usually manage to solve them otherwise.

    So, I have WSL 2 on my Windows 10 work computer, and I can't get it to access anything on the network. I have a strong suspicion that this is related to my company mandating ZScaler (I know, I know...) to protect us from threatsmake :mordac: happy.

    But I'm not sure, so I guess I also possibly need help in weeding out other possibilities first?

    From a WSL (=Ubuntu in my case) shell, ping what.thedailywtf.com works, or rather worked once I fixed the DNS (this is apparently a common issue, /etc/resolv.conf defaults to using the IP of the Windows machine, which isn't a DNS server, but replacing that IP by, say, 8.8.8.8 works).

    So the network interface works and can get outside of my company's network. Good.

    But then, any attempt at any other operation that involves the network times out with messages being variations of "Network is unreachable" / "Cannot initiate connection" / ...

    Notably, this also includes (and it's actually how I got to that first) trying to open any X application (and yes, I set DISPLAY correctly but that doesn't help).

    I tried capturing packets from ZScaler, hoping this could shed some light, but the log file is a 110 MB archive that contains all ZScaler logs so I have no idea where to look. And besides, it's unlikely I would really find much from there.

    I tried following what this page says and exporting/importing all Windows certificates that either contain ZScaler, or my company name, in their name, but that didn't help either.

    I can't turn off ZScaler anymore (I could, in the past), this is controlled by Mordac.

    Any idea how I can:

    • diagnose whether this truly is due to ZScaler blocking stuff?
    • fix that?
    • alternatively, fix it just enough that I can get X applications to run (i.e. connect to the X server that Windows provides for WSL, I think)?
    3 Bulb 1 Reply
  • loopback0
    Discourse touched me in a no-no place

    On both W10 and macOS I had to point apps that needed network access but ignored the OS settings at the ZScaler proxy on 127.0.0.1:9000 for it to work.

    3 Bulb R 2 Replies
  • Bulb

    @loopback0 … except WSL is a VM with its own network ‘namespace’, so its 127.0.0.1 is separate. And question is whether the proxy listens at whatever IP address the Ethernet adapter vEthernet (WSL) has (it's different on each computer).

    2 loopback0 1 Reply
  • loopback0
    Discourse touched me in a no-no place

    @Bulb said in Network access from WSL with ZScaler:

    … except WSL is a VM with its own network ‘namespace’, so its 127.0.0.1 is separate

    But there's presumably a way to get to a service on the host from within WSL? Or at least configure it to use a proxy?

    @Bulb said in Network access from WSL with ZScaler:

    And question is whether the proxy listens at whatever IP address the Ethernet adapter vEthernet (WSL) has (it's different on each computer).

    edit:
    IME it seems to listen on all.

    1 Bulb 1 Reply
  • Bulb

    @loopback0 said in Network access from WSL with ZScaler:

    @Bulb said in Network access from WSL with ZScaler:

    … except WSL is a VM with its own network ‘namespace’, so its 127.0.0.1 is separate

    But there's presumably a way to get to a service on the host from within WSL? Or at least configure it to use a proxy?

    There is a way to get to the host from WSL. The IP address of the Ethernet adapter vEthernet (WSL), that is also set as the gateway of the default route. But the application has to be listening on that address (and not just 127.0.0.1 as many do) and it has to not be blocked by firewall.

    @Bulb said in Network access from WSL with ZScaler:

    And question is whether the proxy listens at whatever IP address the Ethernet adapter vEthernet (WSL) has (it's different on each computer).

    IME it seems to listen on all.

    And rely on the firewall to make it not accessible from the outside? It would be the par for the course for applications from the Theater of Security, but if they actually understand the thing a bit, it won't be.

    2 loopback0 1 Reply
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    Notably, this also includes (and it's actually how I got to that first) trying to open any X application (and yes, I set DISPLAY correctly but that doesn't help).

    Can you verify the X server is indeed running on windows and listening on the IP address of the Ethernet adapter vEthernet (WSL) and you are using that address (and not the outside IP address on which it will either not be listening or will be blocked by the firewall)?

    Windows do have netstat for this though the options are slightly different (there is no -l for listening and you have to use -a for all and grep the LISTENING ones yourself).

    I'd also try setting up something to listen on that IP for TCP and for UDP (I'd use socat if I could find a working Windows build) and test whether you can connect to that from the WSL.

    If you can connect there, then you can either connect to the ZScaler proxy directly, or use some utility (socat could do it) to forward a port from that IP to the Windows localhost.

    If you can't, then another utility, npiperelay, might help setting up such forward, but while I've been meaning to use it to set up ssh agent forwarding for WSL, I didn't get a round toit yet.

    Notes: netcat and npiperelay are on chocolatey, so they have good windows builds. socat isn't, but netcat might be good enough at least for testing.

    1 R 1 Reply
  • loopback0
    Discourse touched me in a no-no place

    @Bulb said in Network access from WSL with ZScaler:

    And rely on the firewall to make it not accessible from the outside? It would be the par for the course for applications from the Theater of Security, but if they actually understand the thing a bit, it won't be.

    You're right, I double checked and it only listens on localhost. Not sure why I thought otherwise.

    1 Tsaukpaetra 1 Reply
  • JBert
    Fake News

    At some point I had some trouble having services interact where some were on the Windows host side and others were in WSL.

    Windows 10 (Enterprise) has a built-in port forwarding thing:

    netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport

    Picking a good listenaddress value is tough because your network card might get a new IP every once in a while.

    1
  • R

    @Bulb said in Network access from WSL with ZScaler:

    Can you verify the X server is indeed running on windows and listening on the IP address of the Ethernet adapter vEthernet (WSL) and you are using that address (and not the outside IP address on which it will either not be listening or will be blocked by the firewall)?

    I already checked that I do have an interface "vEthernet (WSL)" (on the Windows side, with netsh because, uh, that's what I found on the internet). I then made sure that this address was used by DISPLAY. Various sources advocate setting that automatically with e.g. export DISPLAY=$(route.exe print | grep 0.0.0.0 | head -1 | awk '{print $4}'):0.0 but whatever the method, the end result is that the variable is set.

    But this doesn't work, and the only thing that it changes is that now an X application takes a long time to fail (with a "cannot connect" error) instead of failing immediately, which looks a lot like a timeout.

    I don't know how to verify if there is an X server running on the Windows side, and listening to that interface. I assumed from everything I've read about WSL that this was automatic, but I have no idea.

    I'd also try setting up something to listen on that IP for TCP and for UDP (I'd use socat if I could find a working Windows build) and test whether you can connect to that from the WSL.

    You've lost me... I think I understand what you mean (basically capture everything that comes out of that IP from the Windows side, and send something to it from the WSL side, to see if the two ends of the pipe are connected, so to speak), but since there isn't an easily available Windows version of socat that doesn't seem very usable.

    OK, you're also mentioning netcat to do the same, so I'll have a look into that. But I'm still not sure I understand what I'm supposed to do with it...

    1 Bulb 2 Replies
  • R

    @loopback0 said in Network access from WSL with ZScaler:

    the ZScaler proxy on 127.0.0.1:9000

    Do you mean that any application can always use that as proxy to ensure it goes through ZScaler, or is this something specific that has to be configured somehow in ZScaler? (I imagine an admin can always change the defaults, but I don't see any reason why they would have)

    Is there an easy way I can check that (from the Windows side, first, since the WSL side is complicated by the network not being the same)?

    1 loopback0 1 Reply
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    I don't know how to verify if there is an X server running on the Windows side, and listening to that interface. I assumed from everything I've read about WSL that this was automatic, but I have no idea.

    netstat -an and check whether it has anything LISTENING on port 6000 either on 0.0.0.0 (any interface) or that specific IP.

    @remi said in Network access from WSL with ZScaler:

    OK, you're also mentioning netcat to do the same, so I'll have a look into that. But I'm still not sure I understand what I'm supposed to do with it...

    Run nc -l -p 6666 on the Windows side, then echo it works | nc 172.… 6666 on the WSL side and it works should get printed on the Windows side if you can connect.

    1 R 1 Reply
  • R

    @Bulb said in Network access from WSL with ZScaler:

    @remi said in Network access from WSL with ZScaler:

    I don't know how to verify if there is an X server running on the Windows side, and listening to that interface. I assumed from everything I've read about WSL that this was automatic, but I have no idea.

    netstat -an and check whether it has anything LISTENING on port 6000 either on 0.0.0.0 (any interface) or that specific IP.

    Nothing listens on port 6000. There's a bunch of stuff on 9000 which according to what @loopback0 said should be ZScaler, but nothing on 6000. OK, maybe I misconfigured WSL and do need to do something on the Windows side to run an X server? 😕

    Run nc -l -p 6666 on the Windows side, then echo it works | nc 172.… 6666 on the WSL side and it works should get printed on the Windows side if you can connect.

    Thanks. That works (or at least with some tweaking I got it to work). So it seems I can send stuff from WSL to an arbitrary (local) address, which is a good start, at least for the X stuff (no, not that one).

    I really don't know anything about networks and I really appreciate your help! I can read man pages and the like but it's too far out of my knowledge area to even understand the words, so I need some hand-holding...

    1 R dkf 2 Replies
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    netcat to do the same

    Well, netcat is much dumber. Socat can do also udp and can fork to forward connection. However it looks like in Windows you should be able to set up the forwarding from WSL IP to localhost:9000 via netsh interface portproxy, so that's how you add the forwarding.

    @remi said in Network access from WSL with ZScaler:

    alternatively, fix it just enough that I can get X applications to run

    That's the one thing that connecting to the zscaler proxy won't fix.

    1 R 1 Reply
  • R

    @remi said in Network access from WSL with ZScaler:

    OK, maybe I misconfigured WSL and do need to do something on the Windows side to run an X server? 😕

    What confuses me about that is that some page (e.g. this) refer to how to do that with VcXsrv, but then again some other pages (though that one is a highly downvoted answer on SO, but then again this is SO so YMMV) say this is deprecated and nothing is needed nowadays.

    I guess I'll try installing VcXsrv and see how it goes. Though the part that worries me in the first link above is the part about the firewall. Everything network-related is locked down by Mordac, so there is no way I'll be able to edit rules...

    1 Bulb 1 Reply
  • R

    @Bulb said in Network access from WSL with ZScaler:

    However it looks like in Windows you should be able to set up the forwarding from WSL IP to localhost:9000

    That one works! Setting up the redirecting with netsh interface ... then pointing to the right address/port as http_proxy from the WSL side, something like e.g. wget works.

    Though... some other network apps don't work but then again they don't all use http_proxy so that part isn't too worrying.ETA: yeah, I did a dumb in that other app, once I don't leave the proxy line commented-out it also works :rolleyes::facepalm: Besides, I don't really need web-wide access from WSL, what I really want is:

    alternatively, fix it just enough that I can get X applications to run

    That's the one thing that connecting to the zscaler proxy won't fix.

    Eh. Can't say I'm surprised by that, but anyway, I'm making some progress on both fronts, so not all is lost.

    1
  • loopback0
    Discourse touched me in a no-no place

    @remi said in Network access from WSL with ZScaler:

    Do you mean that any application can always use that as proxy to ensure it goes through ZScaler, or is this something specific that has to be configured somehow in ZScaler? (I imagine an admin can always change the defaults, but I don't see any reason why they would have)

    Yeah.
    I think there might be another mode for ZScaler without the local proxy but I'm not sure. The port can be changed too but the default is 9000.

    @remi said in Network access from WSL with ZScaler:

    Is there an easy way I can check that (from the Windows side, first, since the WSL side is complicated by the network not being the same)?

    I manually configured FF to use it as the proxy (as changing it in Edge is restricted by policy) and checked it still had network access. There may be other ways that was the quickest for me.

    1 R 1 Reply
  • R

    @loopback0 Thanks. But since the port redirection worked (from WSL), I can only assume that yes, this is how it's set up on my machine as well.

    So that part is solved, and that's actually great. Thanks everyone for your help.

    One last thing on that: is the port redirection saved somewhere or do I need to redo it every time I reboot (logout?)? I guess it needs to be redone since there is no reason for the IP to use from WSL (i.e. the network interface for WSL) to be always the same?

    I'm not a heavy WSL user (and even less so for network) so I don't mind doing that by hand, but what would be a proper way to do that automatically?

    2 JBert 1 Reply
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    What confuses me about that is that some page (e.g. this) refer to how to do that with VcXsrv, but then again some other pages (though that one is a highly downvoted answer on SO, but then again this is SO so YMMV) say this is deprecated and nothing is needed nowadays.

    The WSLg only works from some very recent build of windows 11 and is a prototype quality, so you may just not have it. If you do have it, DISPLAY should already be set for you, otherwise you don't have it.

    1 R 1 Reply
  • R

    @Bulb Fair enough. We're still Windows 10, so no surprise here. Thanks for clarifying.

    Now before I install any Windows X server, I'm trying to see if I could reuse what I already have. My company already uses Exceed to remotely connect to Linux machines and display their windows as if they were native Windows windows (works pretty well overall, I have to say). So maybe I can use that as well.

    ETA: I don't think that'll work. Exceed TurboX seems to use a different protocol to talk between the remote machine and my local computer, it's not just an X server (though there is one running somewhere behind the scene, just not on my computer). See e.g. p4 here. So much for reusing already installed stuff.

    1 Bulb 3 Replies
  • Bulb

    This post is deleted!
    0
  • Bulb

    @remi It could work. It depends on whether you can lay hands on whatever the Linux machine needs to have installed for the exceed to connect to it. I expected it's just SSH and it would use its X11 forwarding, but maybe not.

    In either case you'll have to start any such service from Windows—because WSL does not run any init—and it'll be a bit less efficient since the traffic will presumably still be encrypted.

    1 R 1 Reply
  • dkf
    Discourse touched me in a no-no place

    @remi said in Network access from WSL with ZScaler:

    Nothing listens on port 6000.

    If there is nothing on port 6000, the Xserver is not running. That's the port it listens on (technically it's the port for the :0 "display", which would be the primary Xserver instance; :1 listens on 6001, :2 on 6002, etc).

    2
  • Bulb

    @remi Your options are basically:

    • Get the Exceed TurboX working.
    • Mobaxterm (free for commercial use if you install it yourself, license needed if installed centrally)
    • XPra (I used it on Linux with containers when directly exposing the main X server resulted in some glitches and I've been meaning to try it on Windows now but didn't get a round toit yet)
    • VcXsrv
    2 C 1 Reply
  • R

    @Bulb said in Network access from WSL with ZScaler:

    @remi It could work. It depends on whether you can lay hands on whatever the Linux machine needs to have installed for the exceed to connect to it. I expected it's just SSH and it would use its X11 forwarding, but maybe not.

    I think not. I vaguely remember that there are some Exceed products that more or less do that (and that we were using them at some point in time), but I'm fairly certain this is not the case with TurboX, which is what we're using now.

    In any case, I tried starting an Exceed session (to some remote Linux machine) and look at whether there seemed to be an X server running on the Windows machine, and no, I couldn't find anything (though I may have missed it).

    But I still managed to solve the problem! (see next post)

    1 Bulb 1 Reply
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    In any case, I tried starting an Exceed session (to some remote Linux machine) and look at whether there seemed to be an X server running on the Windows machine, and no, I couldn't find anything (though I may have missed it).

    The server would not have to run on that network port. It could be part of the Exceed TurboX and run on a named pipe or even just get directly fed from the connection to the client inside the process.

    The important question is what it is connecting to on the remote Linux machine. Whether that is just a ssh server or some Exceed utility.

    1 R 1 Reply
  • R

    So I installed VcXsrv and followed the instructions here to properly set up (and share) an .Xauthority on both sides of the connection.

    I got a "Windows firewall has blocked the application" message at one point, but this was at a time when I had messed up the .Xauthority thing (forgot that PowerShell doesn't use the same syntax as cmd.exe to access environment variables :angry:), so I just ignored it.

    And... it works! 🎉

    I can now start an X application from WSL and it correctly shows up. I haven't fully tested, but that's already good.

    Now ideally I would prefer piggy-backing on Exceed TurboX, especially as this would mean I could tell users to just use what IT already has approved (though they'd still need WSL, but at least that part is 100% Microsoft so hopefully it could work). But since realistically only me and maybe a couple of other people will need that, that's good enough. And besides, from the (semi-)technical doc I linked earlier about TurboX, I'm not sure this is feasible anyway.

    4
  • R

    @Bulb I feel like I need to make you read TFA I linked 😜

    I stopped at this graph:
    f9d1872e-754f-4da5-87d7-6cc179631047-image.png

    which I can't say I really understand, but at least I can see that connections with the "X11/RDP protocol" never go further than the "ETX Connection Node" and nowhere near the "Client Machine" (which I assume is my computer).

    This is what makes me say that a regular X11 client on my machine won't be able to connect to whatever service TurboX has running here.

    1 Bulb 1 Reply
  • Bulb

    @remi It certainly looks like a much more complicated thing. The solution with VcXsrv is the most efficient one anyway; the other things are designed for untrusted networks and do additional encapsulation that would just slow things down even if just a bit.

    1 R 1 Reply
  • R

    @Bulb A bit further in that paper they expound on their "ThinX protocol" (the TXP in the graph above) which apparently is, at the very least, a compressed version of X11 protocol, but with probably some additional tweaks. Regardless of the marketing wank that's part of the description and that I don't care about, the upshot is that it is not X11 and thus it would be extraordinary unlikely that a generic X11 client could talk through it.

    So I guess I would have to run at least a "connection node" on my computer to map from X11 to TXP and that's unlikely to be an easy thing to do given the whole architecture. And if I have to install something locally anyway, VcXsrv works as well, so I have no reason to go any further.

    1 dkf 1 Reply
  • dkf
    Discourse touched me in a no-no place

    @remi said in Network access from WSL with ZScaler:

    the upshot is that it is not X11 and thus it would be extraordinary unlikely that a generic X11 client could talk through it.

    It also appears to be flipped relative to the way X11 works. Which is fine; X was designed with the idea that all computers would be online and world reachable all the time, and it turns out that that's not how reality works (and for very good reasons).

    I'm still irritated that all the original stuff for securing X just got dropped into a deep mire because of US export controls. It wasn't until quite a lot later that the Department of Commerce realised that the rest of the world was going to be using secure communications anyway, whatever restrictions they tried to impose.

    2 Bulb 1 Reply
  • Bulb

    @dkf X11 has to work that way because the programs can get spawned in many ways and some of the intermediaries have no idea X11 even exists, so they have to be able to reach out to the X server, not the other way around. But over an unsecure network the station with the display has to be the client and the station with the apps the server. So the protocol got wrapped in ssh, which provides the securing and turns around the connection direction as appropriate and that's good enough and everybody called it a fortnight.

    1 dkf 1 Reply
  • JBert
    Fake News

    @remi said in Network access from WSL with ZScaler:

    One last thing on that: is the port redirection saved somewhere or do I need to redo it every time I reboot (logout?)? I guess it needs to be redone since there is no reason for the IP to use from WSL (i.e. the network interface for WSL) to be always the same?

    I'm not a heavy WSL user (and even less so for network) so I don't mind doing that by hand, but what would be a proper way to do that automatically?

    It is saved. netsh interface portproxy show all shows me what I setup a couple of months ago, even when I'm not currently using it.

    The way I found out about portproxy is from this Github comment, which includes a script to reset firewall rules and port forwarding on each boot: https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723

    You might need to modify things a bit...

    2 R 1 Reply
  • dkf
    Discourse touched me in a no-no place

    @Bulb It's just a consequence of it all coming from the time before security was a major part of network thinking; networks are far more complicated now than they used to be.

    2 Bulb 1 Reply
  • R

    @JBert said in Network access from WSL with ZScaler:

    It is saved.

    :oh:. Not great.

    a script to reset firewall rules and port forwarding on each boot:

    Yay, great! 🎉

    Thanks for the link!

    2 Bulb 1 Reply
  • Bulb

    @dkf said in Network access from WSL with ZScaler:

    @Bulb It's just a consequence of it all coming from the time before security was a major part of network thinking; networks are far more complicated now than they used to be.

    It is a consequence of leaving things to the layers that are appropriate for them. There would have to be something on the node where the applications run anyway, otherwise it would have problems with the now ubiquitous masquerades, and sshd is good at being that something.

    2
  • Bulb

    @remi The IP address of the WSL instance is different every time, but I can't find whether the address of the vEthernet (WSL) stays the same. If it does, and on that side I don't see much reason why it shouldn't, saving is good enough.

    1 R 1 Reply
  • R

    @Bulb I can't say I understand much about WSL networking. Or Windows networking. Or networking. So I'm mostly throwing stuff and seeing what sticks on the wall. I'd say that's the industry standard anyway. 🍹

    So, WSL can ping both the IP for the "vEthernet (WSL)" and my "regular" eth (Windows) interface ("Ethernet 2" in my case but whatever). The first one is also the one used by default as the DNS server (in /etc/resolv.conf) (which doesn't work, and I need to change, but that part I've solved a long time ago).

    Now if I set a redirect from "vEthernet (WSL)" to 127.0.0.1:9000 (and I use the IP of that interface as http_proxy in WSL), that does not work. If I use "Ethernet 2" instead, it works.

    I have no idea why, but this is how it is. So I need the IP of my real interface, which I have no idea whether it's the same or not (that should be my IP on my company network, I assume), but it sounds somewhat unlikely, especially accounting for connections in different offices, at home etc. So yeah, I guess I can't count on that one being fixed.

    The annoying bit (in adapting the script you linked, which actually is very simple but it gave me the ideas!) is that netsh interface portproxy delete v4tov4 ... (phew!) requires both the "from" port and the "from" address, so I can't just delete all redirections from port 6666, I have to list all existing redirections and delete them one by one (there should be only one...). Not a huge deal, except that I'm not very familiar with PowerShell, but xkcd "I know regular expressionsGoogle" so I'll cope.

    1 Bulb 1 Reply
  • C

    @Bulb said in Network access from WSL with ZScaler:

    @remi Your options are basically:

    • Get the Exceed TurboX working.
    • Mobaxterm (free for commercial use if you install it yourself, license needed if installed centrally)
    • XPra (I used it on Linux with containers when directly exposing the main X server resulted in some glitches and I've been meaning to try it on Windows now but didn't get a round toit yet)
    • VcXsrv

    I am running Debian in WSL. As far as I know, an X server will not work because modern X's rely on systemd, which doesn't work on WSL.

    So I use mobaxterm to run an X11 server. And Xpra to provide session management with remote VMs.

    Xpra is nice.

    1 Bulb 1 Reply
  • Bulb

    @Captain said in Network access from WSL with ZScaler:

    I am running Debian in WSL. As far as I know, an X server will not work because modern X's rely on systemd, which doesn't work on WSL.

    There is no point in running an X-server (well, except Xnest) inside the WSL because it doesn't have access to the display from there anyway. We are talking about running VcXsrv, which is a native Windows application, on the Windows host, and accessing it over tcp/ip over the virtual network.

    @Captain said in Network access from WSL with ZScaler:

    So I use mobaxterm to run an X11 server.

    That's the other option. Except mobaxterm is IIRC free-for-noncomercial only, while VcXsrv is open source.

    @Captain said in Network access from WSL with ZScaler:

    And Xpra to provide session management with remote VMs.

    It is nice there, but not much point in using it locally. Though I did because on my previous notebook (that had Ubuntu) exposing the main X-server to docker containers produced some weird glitches that exposing the Xnest instead avoided.

    2
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    @Bulb I can't say I understand much about WSL networking. Or Windows networking. Or networking. So I'm mostly throwing stuff and seeing what sticks on the wall. I'd say that's the industry standard anyway. 🍹

    So, WSL can ping both the IP for the "vEthernet (WSL)" and my "regular" eth (Windows) interface ("Ethernet 2" in my case but whatever). The first one is also the one used by default as the DNS server (in /etc/resolv.conf) (which doesn't work, and I need to change, but that part I've solved a long time ago).

    Now if I set a redirect from "vEthernet (WSL)" to 127.0.0.1:9000 (and I use the IP of that interface as http_proxy in WSL), that does not work. If I use "Ethernet 2" instead, it works.

    That's … 1. weird and 2. bad. The thing is that the IP address of the vEtherent (WSL) device is not reachable from the outside, so you can expose anything you want there and are not creating any security hazard. But the IP address of the Ethernet 2 is the one that is, obviously, visible from the outside, so that way you are creating a risk as someone else may abuse your ZScaler proxy.

    I don't really know what might be causing this, but I'd try checking the firewall rules. Windows have some by default, so maybe the internal interface is firewalled more strictly than it should be.

    The private range is 172.16.0.0/12 and in my case the IP address of the vEthernet (WSL) and the WSL itself are not even in the same /16, so too strict a firewall, or too strict a routing, are a real option.

    On the other hand if the netcat test worked on that IP, it would mean the port is not firewalled.

    I have no idea why, but this is how it is. So I need the IP of my real interface, which I have no idea whether it's the same or not (that should be my IP on my company network, I assume), but it sounds somewhat unlikely, especially accounting for connections in different offices, at home etc. So yeah, I guess I can't count on that one being fixed.

    It is usually so that you probably get the same in the same location unless you haven't been connected for too long and someone else took it. Definitely not fixed.

    1 R 1 Reply
  • R

    @Bulb said in Network access from WSL with ZScaler:

    That's … 1. weird and 2. bad.

    Yeah, what you're describing (thanks!) confirms what I was suspecting.

    I don't really know what might be causing this, but I'd try checking the firewall rules.

    Problem here is that (almost) everything network-related is quite strongly locked down by IT (even though I have local admin rights). I think I already tried in the past and even looking at existing firewall settings (and rules) is partly hidden. I know some stuff that might not be visible in GUIs might still be accessible through other ways, but in any case I know that I will not be able to change anything. So apart from (maybe?) confirming the reason for the problem, it will not really help me to solve it.

    Mind you, despite what you said about redirecting the public interface being bad (and I do agree with you on that), I am not too worried about it, given that my computer is always either inside the company network, or connected through the VPN. So yeah, sure, it's not a good idea overall, but I think the risks at my level are fairly limited.

    The private range is 172.16.0.0/12 and in my case the IP address of the vEthernet (WSL) and the WSL itself are not even in the same /16, so too strict a firewall, or too strict a routing, are a real option.

    In my case both WSL and vEthernet are on 172.21.0.0/16, but the "real" ethernet (and my whole company network) is on 10.0.0.0/8 (or /16? I have no idea, and don't really care). I wouldn't be surprised if there was indeed something that lets 10.0.0.0/8 go through, but not 172.0.0.0/8.

    On the other hand if the netcat test worked on that IP, it would mean the port is not firewalled.

    I don't remember on which IP the netcat worked, it might have been on the 10.0.0.0/8 one.

    1 Bulb 1 Reply
  • Bulb

    @remi said in Network access from WSL with ZScaler:

    Problem here is that (almost) everything network-related is quite strongly locked down by IT (even though I have local admin rights).

    And would the IT be willing to help? Since you are allowed to use WSL and/or virtual machines, and especially if you need them for work, the argument that allowing the internal 172.16/12 network is more secure than using the external IP might work on them.

    Our IT is helpful, but I work in a medium-sized company, so obviously YMMV.

    1 R 1 Reply
  • R

    @Bulb said in Network access from WSL with ZScaler:

    And would the IT be willing to help?

    :laugh-harder:

    Since you are allowed to use WSL and/or virtual machines,

    Uh... 👀 :seye: 💦 ... something about permission and forgiveness...

    I'm not doing anything prohibited (at least, I don't think so...) but I definitely did not ask for permission before doing all that (including installing WSL). If it turns out that, yes, it is useful for production work, then I will get it validated by them (and I'm phrasing it that way, rather than "asking them if..." because I am fairly confident that they would be OK with it, in the end). But I don't want to do that before I've checked that it's actually feasible, and worth doing for our business.

    I've more or less solved the first part (yes, it's feasible, even though doing it "properly" would require some IT tweaks), thanks to your help (and others in this thread), but I'm still not sure on the second part. We had the idea to try that, but we're not yet sure it's actually answering a problem we have, nor that the solution is really easier for users than the one we currently have, or than another one that might happen Very Soon...

    Our IT is helpful, but I work in a medium-sized company, so obviously YMMV.

    Ours is definitely more acting like a big company IT. Or rather, we (used to?) have a Linux IT that is overall friendly and accommodating, because they are running the systems on which my company makes money, and are very close to the users (and I personally know a couple of their guys). So those are (were...) OK.

    But the Windows systems are managed by corporate IT, which is far more in the "ivory tower" domain and rains down edicts on us (one of the latest ones is "all documents, including emails, must now have a confidentiality level" so sending an email requires clicking through an additional dialog to set the confidentiality level and if someone mistakenly sets to e.g. "confidential" then you can't forward the email but of course nothing prevents you from copy-pasting it :angry: :facepalm:). To top it all, almost all interactions with IT must go through the local helpdesk, who have no say on all those rules.

    Therefore I'm not keen on trying to involve corporate IT in all that until I'm pretty sure it's worth my time.

    But that's all turning into a rant rather than an help request, which I guess I can do since it's my thread, but it's still not really the place.

    2 dkf Gribnit 2 Replies
  • dkf
    Discourse touched me in a no-no place

    @remi said in Network access from WSL with ZScaler:

    But that's all turning into a rant rather than an help request, which I guess I can do since it's my thread, but it's still not really the place.

    🍿

    2
  • Gribnit
    Considered Harmful

    @remi said in Network access from WSL with ZScaler:

    turning into a rant rather than an help request, which I guess I can do since it's my thread

    And you've earned it.

    1
  • Tsaukpaetra
    Notification Spam Recipient

    @loopback0 said in Network access from WSL with ZScaler:

    @Bulb said in Network access from WSL with ZScaler:

    And rely on the firewall to make it not accessible from the outside? It would be the par for the course for applications from the Theater of Security, but if they actually understand the thing a bit, it won't be.

    You're right, I double checked and it only listens on localhost. Not sure why I thought otherwise.

    But can you imagine the shenanigans you could get up to if it did? 😂

    0 loopback0 1 Reply
  • loopback0
    Discourse touched me in a no-no place

    @Tsaukpaetra said in Network access from WSL with ZScaler:

    @loopback0 said in Network access from WSL with ZScaler:

    @Bulb said in Network access from WSL with ZScaler:

    And rely on the firewall to make it not accessible from the outside? It would be the par for the course for applications from the Theater of Security, but if they actually understand the thing a bit, it won't be.

    You're right, I double checked and it only listens on localhost. Not sure why I thought otherwise.

    But can you imagine the shenanigans you could get up to if it did? 😂

    Yes I could do something whacky like filter my Internet traffic through ZScaler on a different computer.

    1
Log in to reply