X11 not working when connected to vpn

[Hugo-Leung]

I have just install WSL2 and have problems using it with cisco anyconnect vpn

Environment

Windows build number: [Version 10.0.19041.685`]
Your Distribution version: [Ubuntu 20.04.1 LTS]
Whether the issue is on WSL 2 and/or WSL 1:WSL2 Linux version 4.19.128-microsoft-standard (oe-user@oe-host) 

Steps to reproduce

In my bashrc, I have included

export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0
export LIBGL_ALWAYS_INDIRECT=1

and

echo $DISPLAY
172.22.144.1:0

I have VcXrv running and this set up works when there is no VPN .

When I start the VPN
I first start cisco anyconnect on windows and connect to my university's VPN.
Then start WSL2 and follow the instruction on
https://community.cisco.com/t5/vpn/anyconnect-wsl-2-windows-substem-for-linux/td-p/4179888
I can now connect to internet
However X11 is no longer working.

Expected behavior

When I enter xeyes, a window should pop up

Actual behavior

xeyes
Error: Can't open display: 172.22.144.1:0

[Hugo-Leung]

I tried using OpenConnect in WSL2 as well.
I can connect the network using OpenConnect, but X11 would also fail in that case, with the same error message when running xeyes

[therealkenc]

/dupe #5805 #5782 are also anyconnect

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[arussu]

@therealkenc, this does not seem to be neither of #5805 #5782.
While the workarounds do fix the internet connection.
The local X server connection is still broken.

[liechtir]

this is still an issue, X11 works when connected to VPN only and the VPN address is used, it does not work when local IP or WSL eth IP is used. Anybody got it working on the local ip?

[Hugo-Leung]

I have recently updated to win11. With wslg and using the anyconnect from the Microsoft store, this is no longer a problem for me.
Before updating to win11, I used mobaxterm and it can handle the X11 automatically even with VPN connected.

[tenable-okumura]

In Windows 11, WSLg can be used as X Server, but WSLg doen't report cursor positions if mouse cursor isn't on any WSLg windows, so xeyes doesn't move...

I disabled WSLg by adding guiApplications=false to .wslconfig:

[wsl2]
guiApplications=false

By this config, VcSsrv + xeyes can be used on Windows 11, but still this problem (with VPN, connection from X clients to X server failed) remains. Hope this will be fixed.

[mmmuir]

I have recently updated to win11. With wslg and using the anyconnect from the Microsoft store, this is no longer a problem for me.

Before updating to win11, I used mobaxterm and it can handle the X11 automatically even with VPN connected.

@Hugo-Leung Do you mean you got it working with mobaxterm setting $DISPLAY to the VPN address? Or using a local address? The former works fine but I still haven't been able to get it to work with a local address (Windows 10, Debian Bullseye Unstable).

[Hugo-Leung]

@mmmuir
When I was using mobaxterm, I also used it for the terminal. So I would select wsl session in Mobaxterm. I believe Mobaxterm had a binary running in my WSL session which handles the X11 forwarding. Therefore, I did not have to set $DISPLAY myself. And I think it worked even when I was connected to a vpn.

But I am no longer using this solution after upgrading to win11 and wslg

[jpfleischer]

i have this issue. i am using docker containers and activating VPNs within the containers so that I don't have to put my entire host computer on the VPN. x11 works without VPN but not with VPN activated in the container.
i actually have two separate containers, each with their own VPN to two different organizations, and strangely, X11 works with one organization and not the other, even though they both use anyconnect.
it is true that WSL != docker but maybe just a little bit since docker uses wsl integration :)

edit: the solution was unrelated to docker, i simply had to use vpn-slice so that only requests destined for my intended resource were routed through VPN.