vatesfr / xen-orchestra

The global orchestration solution to manage and backup XCP-ng and XenServer.
https://xen-orchestra.com
Other
782 stars 264 forks source link

Console doesn't work over VPN connection #2107

Closed Danp2 closed 7 years ago

Danp2 commented 7 years ago

Context

Expected behavior

When I switch to the VM's Console tab, the console to be shown as usual

Current behavior

The console never appears.

olivierlambert commented 7 years ago

No problem here in VPN too (PPTP). Are you sure about your network configuration?

Remember, when we connect to a console, XenServer returns the URL of its management interface, so it must be reachable from XO.

Danp2 commented 7 years ago

@olivierlambert Connecting with OpenVPN and can SSH into both VMs and XS host. I'm wondering if it's a DNS issue. How can I see the exact URL being returned?

olivierlambert commented 7 years ago

It should return the IP address.

To check what is the console URL, use the xe CLI:

  1. xe vm-param-list uuid=<VM UUID>
  2. You should find a console-uuids (SRO) field, take this UUID
  3. xe console-param-list uuid=<Console UUID>

This should return something like that in the location field:

xe console-param-list uuid=8101d885-3137-7ea1-e115-2ea6f67c8e63
uuid ( RO)             : 8101d885-3137-7ea1-e115-2ea6f67c8e63
          vm-uuid ( RO): 8de633ed-0e92-a141-3f02-b603961b4526
    vm-name-label ( RO): FooBar
         protocol ( RO): RFB
         location ( RO): https://192.168.100.5/console?uuid=8101d885-3137-7ea1-e115-2ea6f67c8e63
     other-config (MRW): 
Danp2 commented 7 years ago

Yes, it returns a URL as you've shown above. It may be an issue on my side. This is what I see in the log --

Apr 25 05:04:32 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:04:32 GMT xo:main + WebSocket connection (::ffff:192.168.1.25)
Apr 25 05:04:45 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:04:45 GMT xo:perf blocked for 11ms
Apr 25 05:04:45 xo-5 xo-server[1128]: RRD call: Expected step: 5, received step: 3600. Retry with other timestamp
Apr 25 05:04:46 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:04:46 GMT xo:perf blocked for 65ms
Apr 25 05:04:48 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:04:48 GMT xo:main + Console proxy (dan@mydomain.com - ::ffff:192.168.1.25)
Apr 25 05:04:48 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:04:48 GMT xo:proxy-console connected
Apr 25 05:05:02 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:02 GMT xo:perf blocked for 12ms
Apr 25 05:05:07 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:07 GMT xo:perf blocked for 34ms
Apr 25 05:05:07 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:07 GMT xo:perf blocked for 28ms
Apr 25 05:05:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:09 GMT xo:proxy-console disconnected from the XO client
Apr 25 05:05:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:09 GMT xo:main - Console proxy (dan@mydomain.com - ::ffff:192.168.1.25)
Apr 25 05:05:19 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:19 GMT xo:main + Console proxy (dan@mydomain.com - ::ffff:192.168.1.25)
Apr 25 05:05:19 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:19 GMT xo:proxy-console connected
Apr 25 05:05:25 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:25 GMT xo:perf blocked for 18ms
Apr 25 05:05:37 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:37 GMT xo:perf blocked for 33ms
Apr 25 05:05:42 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:42 GMT xo:perf blocked for 31ms
Apr 25 05:05:57 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:57 GMT xo:perf blocked for 20ms
Apr 25 05:06:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:06:09 GMT xo:main - WebSocket connection (::ffff:192.168.1.25)
Apr 25 05:06:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:06:09 GMT xo:proxy-console disconnected from the XO client

where 192.168.1.25 is the IP address of the openVPN server.

olivierlambert commented 7 years ago

So yes, XOA try to connect on https://192.168.1.25 but if you don't see the console, maybe it can't reach it?

Anything special in the browser console?

Danp2 commented 7 years ago

Not that I've seen thus far.

olivierlambert commented 7 years ago

I can't reproduce here :disappointed:

Danp2 commented 7 years ago

Found this in the FF Browser console -- NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface]

olivierlambert commented 7 years ago

Same with Chrome? Check your extensions, blockers etc.

Danp2 commented 7 years ago

No, the error doesn't appear in Chrome. Neither does the console.

olivierlambert commented 7 years ago

Maybe the console protocol is blocked somehow?

julien-f commented 7 years ago

@Danp2 looks like a native error, probably at the connection level :/

Danp2 commented 7 years ago

@julien-f Can you provide some insight on why the log shows XO connecting to my OpenVPN server (192.168.1.25) instead of the actual XO/ VPN client (172.16.0.6)?

olivierlambert commented 7 years ago

xo-server is connecting to the console URL returned by XenServer API. If your XS host returns https://192.168.1.25/console?uuid=8101d885-3137-7ea1-e115-2ea6f67c8e63 as URL for the console, we'll connect to this URL.

Is it what you meant in your question @Danp2 ?

Danp2 commented 7 years ago

@olivierlambert When there's no VPN involved, this line creates the following log entry --

Apr 25 05:05:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:09 GMT xo:main - Console proxy (dan@mydomain.com - ::ffff:192.168.1.xxx)

where the IP address at the end represents the IP of the PC currently connected to XO.

When the VPN is in use, the log entry looks like this --

Apr 25 05:05:09 xo-5 xo-server[1128]: Tue, 25 Apr 2017 10:05:09 GMT xo:main - Console proxy (dan@mydomain.com - ::ffff:192.168.1.25)

where this IP address is NOT the PC currently connected to XO over the VPN, but rather the VPN server,

For the console redirect to function correctly over the VPN, I would have expected this IP to be 172.16.0.6, which is the IP for the VPN client.

julien-f commented 7 years ago

The displayed address is the source IP of the TCP connection.

I don't know how a VPN works but it appears that xo-server is doing the right thing on its side.

Danp2 commented 7 years ago

Solved the issue by bypassing the traffic on my Untangle NGFW.

olivierlambert commented 7 years ago

@Danp2 to be sure I understand, it was a "network" issue somehow, right?

Danp2 commented 7 years ago

The NGFW has modules that scan the traffic traversing the firewall. In my case, I determined that the Web Monitor module and the Virus Blocker Lite module were scanning this traffic and turning these modules off allowed the console to be displayed as expected.

Instead of turning the modules off, I added a bypass rule so that this traffic wouldn't be processed by any of the modules.

olivierlambert commented 7 years ago

I see. Thanks for the feedback, if I hear someone with a similar issue, I'll redirect it toward this discussion!