[SOLVED] Management IPset doesn't work on 5.4?

[MiBra]

I have two Proxmox servers hosted at OVH. One is running version 5.4, the other 6.0.

I've created the "management" IP set for my IP address on both servers. On 6.0 I can access the system. On 5.4 I lose access when enabling the firewall.

So is the management IP set a new feature of version 6?

 

[Chris]

I have two Proxmox servers hosted at OVH. One is running version 5.4, the other 6.0.

I've created the "management" IP set for my IP address on both servers. On 6.0 I can access the system. On 5.4 I lose access when enabling the firewall.

So is the management IP set a new feature of version 6?

Hi,
no IPsets were already there in 5.x. Can you please post the output of

cat /etc/pve/firewall/cluster.fw
cat /etc/pve/nodes/<nodename>/host.fw
iptables-save

(please retract public IPs) with the firewall enabled for both hosts.
I assume you followed the docs https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_firewall_ip_sets

 

[MiBra]

What I forgot to mention:

Everything works fine when I add this to the firewall rules:

IN ACCEPT -i vmbr0 -source +management -log nolog

But as I understood the manual, this should not be necessary for the management IP set.

Hi,
no IPsets were already there in 5.x. Can you please post the output of

cat /etc/pve/firewall/cluster.fw
cat /etc/pve/nodes/<nodename>/host.fw
iptables-save

(please retract public IPs) with the firewall enabled for both hosts.

I'll post the output in a minute.

 

[Chris]

What I forgot to mention:

Everything works fine when I add this to the firewall rules:

IN ACCEPT -i vmbr0 -source +management -log nolog

But as I understood the manual, this should not be necessary for the management IP set.


I'll post the output in a minute.

The IPs recognized as part of the default management IPs are not to be confused with IPs you add to your IPset "management". It seems that your network configuration is such that you have to explicitly add your IP as you showed in the previous post.

 

[MiBra]

OK, I thought I have found the cause for the problem but I actually didn't.

Unfortunately, I don't understand your reply. In the manual it says, IPs in the standard ip set management get access without an additional IN rule.

 

[Chris]

OK, I thought I have found the cause for the problem but I actually didn't.

Unfortunately, I don't understand your reply. In the manual it says, IPs in the standard ip set management get access without an additional IN rule.

What I mean is that your IPset named "management" is NOT the same as the pve-firewall keeps by default internally. So adding an IP there will not change the firewalls behavior unless you configure this IPset.
Oops, sorry for the false info, it seems we do indeed grab those. Can you please post the requested outputs to see were the problem is?

 

[MiBra]

Here are the outputs.

 

[Chris]

Okay so for the 5.4 cluster.fw you have some additional rules, especially

IN DROP -i vmbr0 -log nolog

at the end.
This presumably drops your packets (without me knowing your exact network configuration) and is not present in the 6.0 cluster.fw.
And from the out of the iptables-save you see that traffic over vmbr0 will get dropped before it comes to the rules for the default management IP set

0: -A PVEFW-HOST-IN -i vmbr0 -m set --match-set PVEFW-0-management-v4 src -j RETURN <- Packets in vmbr0 in management IPset return (if this is not present they will get droped by (2) before they reach (3)

1: -A PVEFW-HOST-IN -i vmbr0 -p icmp -m set --match-set PVEFW-0-ovh-monitoring-v4 src -j RETURN
2: -A PVEFW-HOST-IN -i vmbr0 -j DROP <- Drops your traffic comming

-> Rules for management IPset addrs
3: -A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 8006 -j RETURN
4: -A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 5900:5999 -j RETURN
5: -A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 3128 -j RETURN
6: -A PVEFW-HOST-IN -p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 22 -j RETURN

Try again without this rule and see if you then get connectivity.

 

[MiBra]

Thank you very much, Chris, I don't know how I could overlook that. It does work now.

Do I understand it correctly that what I wanted to do with that last rule is already covered with "Input Policy: DROP" in the firewall settings?

 

[Chris]

You are welcome.
If you have once again a look at the PVEFW-HOST-IN chain, you will find

-A PVEFW-HOST-IN -j PVEFW-Drop
-A PVEFW-HOST-IN -j DROP

meaning all traffic which is not returned before that will get dropped, which stems indeed from the "Input Policy: DROP" in the firewall settings.