Managing a host using a proxy

McHenry

We are using a 1:1 NAT so 443:443. I just disabled and then reenabled the server and received the following error:

server.enable
{
  "id": "e2744b37-011a-4391-9145-caacb74dae55"
}
{
  "code": "ERR_INVALID_URL",
  "input": "'https://IptW7OlWcBeMdXeArx6QEIH30HvB7X4bmPKBhcxE@10.27.50.159/",
  "message": "Invalid URL",
  "name": "TypeError",
  "stack": "TypeError: Invalid URL
    at new URL (node:internal/url:797:36)
    at new Xapi (file:///opt/xo/xo-builds/xen-orchestra-202410010110/packages/xen-api/index.mjs:159:19)
    at new Xapi (file:///opt/xo/xo-builds/xen-orchestra-202410010110/@xen-orchestra/xapi/index.mjs:145:5)
    at new Xapi (file:///opt/xo/xo-builds/xen-orchestra-202410010110/packages/xo-server/src/xapi/index.mjs:75:5)
    at new Xapi (/opt/xo/xo-builds/xen-orchestra-202410010110/@xen-orchestra/mixin/legacy.js:62:22)
    at XenServers.connectXenServer (file:///opt/xo/xo-builds/xen-orchestra-202410010110/packages/xo-server/src/xo-mixins/xen-servers.mjs:313:44)
    at Xo.enable (file:///opt/xo/xo-builds/xen-orchestra-202410010110/packages/xo-server/src/api/server.mjs:121:3)
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202410010110/@vates/task/index.js:169:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202410010110/@vates/task/index.js:153:20)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202410010110/packages/xo-server/src/xo-mixins/api.mjs:402:20)"
}

The URL is as reported by XO

linuxuser@SVR11336:~$ xo-cli proxy.getAll
[
  {
    address: '10.27.50.159',
    id: '8a3128f0-101a-4ca0-8bc3-4fccacbf25c7',
    name: 'Proxy 2024-10-01T04:26:42.665Z',
    url: 'https://IptW7OlWcBeMdXeArx6QEIH30HvB7X4bmPKBhcxE@10.27.50.159/',
    vmUuid: 'a7dc9473-0a34-3f1a-49fb-40080d456859'
  }
]

The GUI does not show any errors:

Not sure if this helps however if I browse to the URL I am presented with:

olivierlambert

@McHenry said in Managing a host using a proxy:

10.27.50.159

So this is the "public" IP of your NAT/firewall machine?

Have you tried to add :443 at the end in case?

McHenry

@olivierlambert said in Managing a host using a proxy:

So this is the "public" IP of your NAT/firewall machine?
Yes

Have you tried to add :443 at the end in case?
Yes

I am using XO and I have tried with XOA and get the same result.

olivierlambert

Let me do a recap on what I have (because it actually works for our own prod):

10.27.50.4 is the IP address of your pool master, that's behind a NAT, right?
10.27.50.159 is the NAT/fw address that you can reach from your XOA, right? In that case, I find it weird it's exactly the same range than the server behind the NAT (for example, in my case, I have a purely public IP as the NAT/fw address, and then a private IP in another range for the host and the proxy)
What's your XO Proxy IP? Can it reach the IP address of the pool master?

All in all I think it's an environment/configuration issue than anything else.

McHenry

@olivierlambert

xcp-ng host
Private: 192.168.1.4
Public: 10.27.50.4

XO Proxy
Private: 192.168.1.159
Public: 10.27.50.159

XOA
Private: 192.168.1.199
Public: 10.27.0.199

XOA can connect to the xcp-ng host
XOA can connect to the xo proxy

My problem appears to be similar to this post that appears to have been resolved with a proxy upgrade that was problematic.
https://xcp-ng.org/forum/topic/6626/xo-proxy-not-working

When I try to upgrade the proxy I receive the following error:

proxy.upgradeAppliance
{
  "id": "5271ae70-d243-4722-bba5-e4e381d1703b"
}
{
  "code": -32000,
  "message": "unknown error from the peer"
}

olivierlambert

Is this kind of a test network?

McHenry

@olivierlambert

No.

Edit: We are testing xcp-ng as an alternative to HyperV and would require the proxy functionality.

olivierlambert

I don't get why you have similar ranges between different networks

@julien-f any idea why proxy doesn't work? Sounds like a topology or connectivity issue to me

McHenry

@olivierlambert

We have multiple distinct networks at client sites all connected via VPN, some use the same range.

Each is contactable using a unique network range via NAT 10.27.X.X

Works well and has done for years.

olivierlambert

Obviously there's something wrong otherwise it would work (as we have many users relying on the proxy). It's hard to tell more without having a support tunnel open and trying to poke around.

McHenry

@olivierlambert

OK, so how do we do that?

olivierlambert

Since we are all ultra mega busy right now (despite we hire like crazy), your best chance is to be seen as a valuable lead so we can spare some engineer time to take a look and see if there's an obvious issue: https://vates.tech/contact

Or wait for someone in the community to dig deeper in here, depends on how patient (or how in a hurry) you are

McHenry

@olivierlambert

When deploying a proxy from the terminal what Xen Orchestra credentials are used?
https://xen-orchestra.com/blog/xo-proxy-a-concrete-guide/

Is this my Vates account, the login creds for the XOA or the login creds for the xcp-ng server it is being installed on?

olivierlambert

You deploy from this script directly from your XCP-ng host. Then, the proxy doesn't have credentials but a token.

McHenry

@olivierlambert

Sorry, still unclear on what creds to use here:

olivierlambert

Those are your Vates/Xen.orchestra.com creds

nathanael-h

Hello @McHenry I wanted to share with you that we've just build a new images for XOA and the proxy. You might want to try it and keep us posted.

McHenry

@olivierlambert

Got it. To assist in my understanding of the ecosystem can you advise the purpose of these creds.

Is it simply to allow Vates to monitor usage of proxies? As the install completes even if no creds are entered, are they optional?

olivierlambert

IIRC, it's needed to attach a proxy support license to your appliance. If you don't do it here, you'll have to register afterward. That's because proxies are an extra product invoiced per product.

olivierlambert

Adding @julien-f in the convo for confirmation.