ipfilter-net and ACCEPT on input

XN-Matt

Well-Known Member
Aug 21, 2017
88
7
48
42
Hi All,

So we're playing with "ipfilter-net*" to specifically state what IPs a VM is allowed to use - that works fine.

However, if the INPUT firewall is set to ACCEPT, it allows all traffic to any IPs and not just those in the IPset.

I would say that the INPUT needs to still honour what is set in the IPset as that is set as a "only allow these IPs" so no matter what the user could create in their firewalls on the node via API, that rule should never be overridden - i.e should always be the highest priority.

If not, it largely makes the feature useless.

Matt
 
However, if the INPUT firewall is set to ACCEPT, it allows all traffic to any IPs and not just those in the IPset.


You refer probably to input policy!?

I would say that the INPUT needs to still honour what is set in the IPset as that is set as a "only allow these IPs" so no matter what the user could create in their firewalls on the node via API, that rule should never be overridden - i.e should always be the highest priority.

If not, it largely makes the feature useless.


I cannot agree: input policy defines the default (i.e. how to handle packets which do not match to any filter), it is up to the administrator if the system should work like this or not. Even some combinations will be useless: any kind of tools have to be used responsible and have to be used by experts who know what they are doing.
 
What about where the system admin wants to limits what IPs a VM should be able to use but still allow the user to allow all traffic to those IPs? If we don't enable the firewall per VM, the IPsets where allowed IPs can be set don't work.

Look at Onapp, which does do this. You set the IPs on the VM. Any other IP that is mounted on the machine cannot communicate in, or out.

The user can then setup a firewall and any rules of that but they cannot allow traffic to/from IPs that they do not have. The firewall set at the top level is cannot be overridden but works even if the user turns off their "custom" firewall per VM.

So in the example you mention, we'd have to either set INPUT allow which then allows anything regardless of the IPset, or deny which then rejects everything bar traffic to the IP but then would block anything else until specific rules are added.

99% of people don't even use such a firewall that we've seen but we still need to be able to use it to block un-assigned IPs but allow them to have the function should they want it.
 
Look at Onapp, which does do this. You set the IPs on the VM. Any other IP that is mounted on the machine cannot communicate in, or out.
OnApp uses their own UI to do this, so it is unclear (not open source), what is happening underneath exactly.

In general, firewalls are mostly set to block all traffic and then there are exceptions to it. To that there are also different layers for blocking traffic. Cluster, hosts or VMs can have a set of rules and you can also specify your own specialties (what ever goes with netfilter).
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_pve_firewall
https://en.wikipedia.org/wiki/Iptables
 
The GUI itself isn't relevant as i've explained how it works as you can see from the host node via the command line.

The node sets what IPs can be used and communicate to/from the VM and this is regardless if the firewall is enabled or disabled on the VM. Even if the user sets their VM firewall to enabled with everything to be accepted, it still will only accept IPs to that VM that the node is told to allow.

From the docs, this seems to be how IPsets should be used. You set the IPs allowed on the VM and it should only allow those regardless of what the VM firewall status is set to or allows (i.e ALLOW everything should not override the IPset in terms of destination or source to only allowed addresses.

It's worth noting there have been a few threads about this on these forums and it would be nice to get something implemented because currently there is little to no protection in users and their binding of IPs whilst allowing the user their own node-based firewall.
 
The GUI itself isn't relevant as i've explained how it works as you can see from the host node via the command line.
So, how does OnApp do it? :)

The node sets what IPs can be used and communicate to/from the VM and this is regardless if the firewall is enabled or disabled on the VM. Even if the user sets their VM firewall to enabled with everything to be accepted, it still will only accept IPs to that VM that the node is told to allow.
That's what I meant with multiple layers, as we also have a node firewall.

From the docs, this seems to be how IPsets should be used. You set the IPs allowed on the VM and it should only allow those regardless of what the VM firewall status is set to or allows (i.e ALLOW everything should not override the IPset in terms of destination or source to only allowed addresses.
This depends at which point the input applies. In the same INPUT chain a "allow all" rule matches regardless of previous or passt allow rules. Only deny rules before the "allow all" would block certain traffic.

It's worth noting there have been a few threads about this on these forums and it would be nice to get something implemented because currently there is little to no protection in users and their binding of IPs whilst allowing the user their own node-based firewall.
Which protection do you mean, of users or from? As basically these rules protect the infrastructure. On a node, you could use a iptables rule below to match the IP/MAC.
Code:
iptables -A FORWARD -s $IP -m mac --mac-source $MAC -j ACCEPT
 
Well, technically how it is done is as explained.

So maybe you can add something where with a VM you set the IPs used and it creates the last example automatically based on the MAC and the IPs listed against the VM preferably via the API.

Currently, in a shared environment, proxmox isn't great if someone wants to go and just try and use IPs they're not assigned.
 

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 yours easily in our online shop.

Buy now!