pveproxy - is disabling tls or moving its port possible?

[VA1DER]

I'm working with a new PVE install over top of Debian. I want to disable tls and connect to pveproxy over vanilla http to avoid exposing PVE's UI to the internet.

I found this instruction which speaks toward changing pveproxy's listening port, but the configuration file it references doesn't exist and the instruction doesn't actually show the options.

Can pveproxy be made to use vanilla http?
Can pveproxy be moved to a different port?

I've reverse proxy if I have to, but I figured there must be a way to configure it more finely.

 

[fba]

I want to disable tls and connect to pveproxy over vanilla http to avoid exposing PVE's UI to the internet.

Sorry, but why will disabling a security layer prevent exposure of an interface? Have a check on routing, firewall rules and so on instead.

There is no way to change the port in Proxmox VE. You can try rewriting it with a firewall as described in this thread.

 

[VA1DER]

why will disabling a security layer prevent exposure of an interface?

Because the only included security layer is TLS, which isn't an optimal transport for something you don't intend to expose to the Internet. TLS only properly works over a LAN/VPN with custom certificate infrastructure and manual browser trust, or manual security overrides.

As it stands, TLS in pveproxy selects for internet exposure to make it work properly. And, in fact, the default configuration exposes the interface to the whole world.

Allowing TLS to be disabled better accommodates more appropriate security layers. Vanilla http over ssh tunnels or wireguard.

Is it impossible to use otherwise? No. Does the current manifestation discourage the use of appropriate transports? Yes.

I ended up using caddy as a reverse proxy. It works, but when you think about it it's pretty clumsy.

 

[fba]

Allowing TLS to be disabled better accommodates more appropriate security layers. Vanilla http over ssh tunnels or wireguard.

That's an interesting opinion that wireguard has problems with https, but not with http. I can not even imagine why that should be the case.
But well, you used a reverse proxy to solve your problem, on a separate host most likely?

 

[VA1DER]

That's an interesting opinion that wireguard has problems with https

Wireguard has no problems with https. Browsers have problems with https over non-routable IPs. Browsers have problems with https over ssh tunnels and (without exotic configurations) wireguard connections.

Apparently I'm not making my overall point well enough. My point is that https and TLS (slash public certificate infrastructure) is not the best transport for a non-public administrative-only interface. Your home cable/fibre modem's UI is probably a web interface too, but I suspect you'd be aghast if the vendor exposed that interface to the internet. You are probably also using vanilla http to talk to it and if you access it remotely you probably also tunnel that connection over ssh or Wireguard (or OpenVPN, etc etc).

you used a reverse proxy to solve your problem, on a separate host most likely?

Same host. I reverse proxy http -> https (with certificate checking disabled) using caddy and listen on 127.0.0.1:8005. This lets me either use ssh to tunnel to it, or (what I normally do) forward a port from my wireguard interface to it.

It still uses TLS internally to talk from caddy to pveproxy, but at least it's not exposed and browsers like it.

Caddy is quick and easy to make a config for this for:

:8005 {
    bind 127.0.0.1
    reverse_proxy https://localhost:8006 {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

 

[fba]

https and TLS (slash public certificate infrastructure) is not the best transport for a non-public administrative-only interface.

If the interface is not required to be accessed from a public network, why make it accessible from there first place? It should be accessible from trusted networks only. What additional measures you take (and the devices provide) is up to you and the it security requirements needed to be fulfilled.
Why not get a Let's Encrypt certificate ready for your PVE or one from the local CA used in the environment (if available)? Then you would improve security just by providing means for protecting authenticity in communication.