My "pveproxy" file doesn't work.

dominikdev

New Member
Jan 28, 2021
6
0
1
16
Hey,

I have a small problem. I was trying to disable access to the proxmox web panel for the IP address and enable it for my domain. As I saw on the proxmox website (https://pve.proxmox.com/pve-docs/pveproxy.8.html) I can create the pveproxy file for Host based Access Control. I did set up a nginx reverse proxy that points to 127.0.0.1:8006, and I did create the pveproxy file with the following content:

Code:
ALLOW_FROM="127.0.0.1"
DENY_FROM="all"
POLICY="allow"

And I did restart the pveproxy.

But somehow I can still access the web UI with the IP address.

Does anyone know why?

Greetings
 

Stoiko Ivanov

Proxmox Staff Member
Staff member
May 2, 2018
7,381
1,186
164
How are you checking access to the 'IP'?
what's the output of
Code:
curl https://<PVE-IP>:8006/
(run from a client, which is not the PVE-installation :)
which lines are written to /var/log/pveproxy/access.log
 

ph0x

Renowned Member
Jul 5, 2020
1,326
212
68
/dev/null
I can reproduce this. The access log shows
Code:
::ffff:172.16.10.100 - root@pam [28/04/2021:23:08:21 +0200] "GET /api2/json/cluster/resources HTTP/1.1" 200 2221
I already tried the v4-in-v6 notation in /etc/default/pveproxy but that also has no effect.

Code:
ALLOW_FROM="::ffff:127.0.0.1,::ffff:172.16.10.10,::ffff:172.16.10.11,::ffff:172.16.10.12"
DENY_FROM="all"
POLICY="allow"
CIPHERS="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA"
DHPARAMS="/etc/pve/pveproxy.dh"

Setting policy to "deny" also denies the entries of ALLOW_FROM btw ....

Even more: port 8006 is restricted in pve-firewall to cluster members only. Still works from other machines, though ...
 
Last edited:

oguz

Proxmox Retired Staff
Retired Staff
Nov 19, 2018
5,207
693
118
I can reproduce this. The access log shows
Code:
::ffff:172.16.10.100 - root@pam [28/04/2021:23:08:21 +0200] "GET /api2/json/cluster/resources HTTP/1.1" 200 2221
I already tried the v4-in-v6 notation in /etc/default/pveproxy but that also has no effect.

Code:
ALLOW_FROM="::ffff:127.0.0.1,::ffff:172.16.10.10,::ffff:172.16.10.11,::ffff:172.16.10.12"
DENY_FROM="all"
POLICY="allow"
CIPHERS="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA"
DHPARAMS="/etc/pve/pveproxy.dh"

Setting policy to "deny" also denies the entries of ALLOW_FROM btw ....

Even more: port 8006 is restricted in pve-firewall to cluster members only. Still works from other machines, though ...

ALLOW_FROM only works with regular IP notation at the moment. the v4-in-v6 notation is only for logs and optionally for LISTEN_IP (though LISTEN_IP will also take a regular IPv4 or IPv6 address) [0]

from what i can guess, the original issue is likely from nginx proxy configuration.

Code:
ALLOW_FROM="127.0.0.1"
DENY_FROM="all"
POLICY="allow"

works here without nginx proxy.

[0]: https://pve.proxmox.com/pve-docs/pveproxy.8.html#_listening_ip
 
Last edited:

ph0x

Renowned Member
Jul 5, 2020
1,326
212
68
/dev/null
I tried it with traditional notation before and it also didn't work.
I will try tonight without the proxy and report back. It's still something that needs to be resolved, especially the not respected firewall rule.
 

ph0x

Renowned Member
Jul 5, 2020
1,326
212
68
/dev/null
I disabled nginx service, edited /etc/default/pveproxy to use v4 notation and restarted pveproxy service.

The error remains:
With policy "allow" every machine can reach the GUI, although forbidden by pveproxy file AND pve-firewall.
With policy "deny" even the allowed machines are not able to reach GUI or show VM statuses, respectively.
 

Stoiko Ivanov

Proxmox Staff Member
Staff member
May 2, 2018
7,381
1,186
164
Could it be a bug?
Seems like a bug - I'll take a closer look - could reproduce the issue with

Code:
ALLOW_FROM="127.0.0.1"
DENY_FROM="all"
POLICY="allow"
according to:
https://pve.proxmox.com/pve-docs/pveproxy.8.html
access should be denied from anything apart from 127.0.0.1

I'd suggest switching the policy to deny and remove the DENY_FROM line
(which works in my tests)

. It's still something that needs to be resolved, especially the not respected firewall rule.
please check the output of iptables-save how this rule is set - I doubt that there is a general problem with iptables filtering

I hope this helps

EDIT: realized after the initial post that this is a bug indeed...
 
Last edited:

ph0x

Renowned Member
Jul 5, 2020
1,326
212
68
/dev/null
Thank heavens, because I played with it now in a dozen variants and regardless of what I set, ALLOW_FROM is never respected.
Will try to work around with your suggestion.

Edit: Unfortunately, your workaround also doesn't do the trick. ALLOW_FROM still is unrespected, meaning every client is denied with policy="deny".

Edit2: iptables-save | grep 8006 allows IN from group management (which I haven't defined) and OUT to the management subnet.
Ergo, there is no rule allowing traffic from any client to 8006 and yet it's possible ...
 
Last edited:

Stoiko Ivanov

Proxmox Staff Member
Staff member
May 2, 2018
7,381
1,186
164
Edit: Unfortunately, your workaround also doesn't do the trick. ALLOW_FROM still is unrespected, meaning every client is denied with policy="deny".
Thanks for pointing this out - and sorry for my confusion (and repeated insisting that it works) - I think I found the issue and send an initial patch for discussion to the mailing-list:
https://lists.proxmox.com/pipermail/pve-devel/2021-May/048048.html

once this or an improved version is merged the ACLs should work as they used to!

Edit2: iptables-save | grep 8006 allows IN from group management (which I haven't defined) and OUT to the management subnet.
Ergo, there is no rule allowing traffic from any client to 8006 and yet it's possible ...
I'd suggest to check the complete output - grepping for a port always only shows part of the story - e.g. you don't see what the policy of each chain is - and if there's a general allow-rule below that lets the traffic pass

I hope this helps!
 

ph0x

Renowned Member
Jul 5, 2020
1,326
212
68
/dev/null
Thanks for the quick support. And no worries, I can imagine how often a "worst case scenario" reveals to be just a configuration issue and therefore you take such reports easily at first.

I'll take a look into the firewall stuff and open another thread in case. I'm already pretty sure that I didn't misconfigure it, but we'll see.

Thanks again! :)
 
  • Like
Reactions: Stoiko Ivanov

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!