/qubes-issues

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x2goclient not working via VPN Proxy #2532

Closed
seekamp opened this Issue Dec 22, 2016 · 7 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
  Far in the future
3 participants
@seekamp @marmarek @andrewdavidwong
@seekamp

seekamp commented Dec 22, 2016

Qubes OS version: R3.2

Affected TemplateVMs: N/A

Expected behavior:

I created a ProxyVM for VPN access. I am able to connect to the VPN successfully. I am trying to use x2go which uses X11 forwarding I believe over ssh. I am able to login to the target server using ssh successfully. I can also telnet using port 22 successfully, so the port is not blocked. I expect x2goclient to connect successfully and launch the desktop image from the server.

Actual behavior:

x2go client hangs during the connection.

Steps to reproduce the behavior

  • Install and configure x2go on the server (I had done this already as I have been using x2go for years).
  • Create a proxy VM for the VPN.
  • Configure an AppVM to use the VPN proxy VM.
  • Install x2goclient in the AppVM.
  • Launch the AppVM and connect to the VPN.
  • Start x2goclient and create and start a session to the target server. I used parameters that work when connecting from other Linux desktops.

General notes:

Is it possible that launching of another X window from within an application is not allowed by Qubes?

Related issues:
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Dec 23, 2016

Member
Member

marmarek commented Dec 23, 2016

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Dec 23, 2016

Member

Is this actually a Qubes issue? Unless there's some clear reason for think that it is, I'm inclined to close this as notourbug.

Is it possible that launching of another X window from within an application is not allowed by Qubes?

If the answer rests on this question, then this is actually a much more general issue.
Member

andrewdavidwong commented Dec 23, 2016

Is this actually a Qubes issue? Unless there's some clear reason for think that it is, I'm inclined to close this as notourbug.

Is it possible that launching of another X window from within an application is not allowed by Qubes?

If the answer rests on this question, then this is actually a much more general issue.

@andrewdavidwong andrewdavidwong added the C: other label Dec 23, 2016

@seekamp

This comment has been minimized.

Show comment
Hide comment
@seekamp

seekamp Dec 23, 2016

seekamp commented Dec 23, 2016

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@andrewdavidwong

andrewdavidwong Dec 23, 2016

Member

Hi Andrew: Or do you go by "David" or "Andrew David"?

"Andrew" is fine, thanks.

So I plan to try to continue investigating this, but first some context. I have been using x2go to access my work desktop for several years from multiple PCs (at least 3). Admittedly they all were running Ubuntu derivatives, but I would be surprised if the problem were in Fedora 24. The connection over port 22 is happening and it asked me to verify the fingerprint of the server I contacted so the initial ssh handshake seems to be happening fine. I am going to try to find some additional logging that will hopefully tell me exactly where the hang is occurring. I understand you wanting to close the issue if it is not a Qubes issue (I have been in development for over 30 years and I am very familiar with bug tracking etc.), but wouldn't you want to try to find out if it really is Qubes related or not?

Yes, of course. However, based on the initial report, it sounded like there was no particularly strong reason for thinking that it was a Qubes bug rather than an upstream one. Given that we have well over 600 open issues and almost zero chance of resolving all of them in the foreseeable future, it seems reasonable to be somewhat selective about which new issues we introduce. However, given that you believe there is such a reason and that you're willing to investigate the matter, I'm more than happy to keep this open!

Or are you saying I should have posted it is an issue or question in one of the Qubes-related google groups instead?

In this case, a GitHub issue is fine.

Also, do you know for a fact whether or not launching another X window or X11 forwarding over ssh is supported?

I do not, but given that Marek said that it should theoretically "just work," I would assume it's supported.

Thanks. P.S. I am very interested in Qubes and would like to try to contribute code to it in the future.

Glad to hear it! We would welcome that!
Member

andrewdavidwong commented Dec 23, 2016

Hi Andrew: Or do you go by "David" or "Andrew David"?

"Andrew" is fine, thanks.

So I plan to try to continue investigating this, but first some context. I have been using x2go to access my work desktop for several years from multiple PCs (at least 3). Admittedly they all were running Ubuntu derivatives, but I would be surprised if the problem were in Fedora 24. The connection over port 22 is happening and it asked me to verify the fingerprint of the server I contacted so the initial ssh handshake seems to be happening fine. I am going to try to find some additional logging that will hopefully tell me exactly where the hang is occurring. I understand you wanting to close the issue if it is not a Qubes issue (I have been in development for over 30 years and I am very familiar with bug tracking etc.), but wouldn't you want to try to find out if it really is Qubes related or not?

Yes, of course. However, based on the initial report, it sounded like there was no particularly strong reason for thinking that it was a Qubes bug rather than an upstream one. Given that we have well over 600 open issues and almost zero chance of resolving all of them in the foreseeable future, it seems reasonable to be somewhat selective about which new issues we introduce. However, given that you believe there is such a reason and that you're willing to investigate the matter, I'm more than happy to keep this open!

Or are you saying I should have posted it is an issue or question in one of the Qubes-related google groups instead?

In this case, a GitHub issue is fine.

Also, do you know for a fact whether or not launching another X window or X11 forwarding over ssh is supported?

I do not, but given that Marek said that it should theoretically "just work," I would assume it's supported.

Thanks. P.S. I am very interested in Qubes and would like to try to contribute code to it in the future.

Glad to hear it! We would welcome that!
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Dec 23, 2016

Member
Member

marmarek commented Dec 23, 2016

@seekamp

This comment has been minimized.

Show comment
Hide comment
@seekamp

seekamp Dec 23, 2016

seekamp commented Dec 23, 2016

@andrewdavidwong andrewdavidwong added bug help wanted labels Dec 24, 2016

@andrewdavidwong andrewdavidwong added this to the Far in the future milestone Dec 24, 2016

@seekamp

This comment has been minimized.

Show comment
Hide comment
@seekamp

seekamp Dec 24, 2016

So I spent hours yesterday trying to resolve this. I temporarily set up the VPN in the sys-net. I still had the same hang. I looked at the xsession-x2go* file on the server. Nothing was getting logged there. It seems the hang occurs before the xsession is created. I checked the logging on the server. The only thing logged was the successful login.

Today what I did was try the debian 8 template in Qubes instead. Suprisingly, that worked perfectly. So my work domain which will I will use for VPN/x2go is now based on debian 8.

I am not aware of a known problem with x2goclient on fedora24. As I side note I tried x2go client on the fedora 23 template and it failed to connect successfully as well (symptoms the same as with fedora 24).

I don't know if there could be differences in how the fedora templates work in Qubes versus the debian ones that could explain the different behavior, but at this point given it works with the debian template I guess I will close the issue.

seekamp commented Dec 24, 2016

So I spent hours yesterday trying to resolve this. I temporarily set up the VPN in the sys-net. I still had the same hang. I looked at the xsession-x2go* file on the server. Nothing was getting logged there. It seems the hang occurs before the xsession is created. I checked the logging on the server. The only thing logged was the successful login.

Today what I did was try the debian 8 template in Qubes instead. Suprisingly, that worked perfectly. So my work domain which will I will use for VPN/x2go is now based on debian 8.

I am not aware of a known problem with x2goclient on fedora24. As I side note I tried x2go client on the fedora 23 template and it failed to connect successfully as well (symptoms the same as with fedora 24).

I don't know if there could be differences in how the fedora templates work in Qubes versus the debian ones that could explain the different behavior, but at this point given it works with the debian template I guess I will close the issue.

@seekamp seekamp closed this Dec 24, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment