Geo IP block help

H

henryd99

Member
Dec 13, 2023
9
2
8
Hi all,

Current running a 3 node cluster with version 8.2.4, for what I can see its running iptables and not nftables.

We wish to lock down our individual nodes or a cluster as a whole using GeoIP rule IPsets, and using the GUI for this is not an option (We are using the cluster/Node/VM built in
firewall functionality in GUI for basic rules).

Does anyone have any recommendations on making this as efficient as possible as well as how to ensure this stays persistent through reboots, upgrades, etc..

Thank you.
 
From my point of view it is not best practice to connect a PVE cluster directly to the outer internet. There should always exist a router with filtering capabilities. In that picture the router would do Geo blocking, beside other things. My recommendation is to re-evaluate the possibility of an implementation of something like OpnSense in front of your cluster.

That said... PVE is Debian, and there are a vast number of small projects out there implementing this. Just note that there is a) a non-zero chance to lockout yourself and b) that you may interfere with the PVE integrated solution.

One random(!) article describing an as-simple-as-possible approach, just as an example: https://blog.ip2location.com/knowledge-base/how-to-block-ip-addresses-from-a-country-using-ipset/

Good luck!
 
  • Like
Reactions: _gabriel
UdoB said:
From my point of view it is not best practice to connect a PVE cluster directly to the outer internet. There should always exist a router with filtering capabilities. In that picture the router would do Geo blocking, beside other things. My recommendation is to re-evaluate the possibility of an implementation of something like OpnSense in front of your cluster.

That said... PVE is Debian, and there are a vast number of small projects out there implementing this. Just note that there is a) a non-zero chance to lockout yourself and b) that you may interfere with the PVE integrated solution.

One random(!) article describing an as-simple-as-possible approach, just as an example: https://blog.ip2location.com/knowledge-base/how-to-block-ip-addresses-from-a-country-using-ipset/

Good luck!
Click to expand...
Hi,

Thanks for the reply.

Yes I agree, our other clusters we own are all on private IPs only accessible via VPNs, but in this case we have a 3 node cluster with a server vendor in a Datacentre in London.

The Datacentre, do not offer firewall/routers or even virtualised in that environment.
All nodes API/GUI access are locked down with access only from our VPNs.

The GEO block is only to affect ports 5060:5090, everything else is fine using built in Firewall.

Thanks
 
  • Like
Reactions: UdoB
After a try , ipset created with PVE UI cannot be managed with ipset direcly.
ipset created with PVE UI can be updated with CLI pvesh create /cluster/firewall/ipset/my-pve-ipset-name --cidr x.x.x.x/y but too slow if many lines.
editing cluster.fw directly is instant.
 
UdoB said:
From my point of view it is not best practice to connect a PVE cluster directly to the outer internet. There should always exist a router with filtering capabilities. In that picture the router would do Geo blocking, beside other things. My recommendation is to re-evaluate the possibility of an implementation of something like OpnSense in front of your cluster.

That said... PVE is Debian, and there are a vast number of small projects out there implementing this. Just note that there is a) a non-zero chance to lockout yourself and b) that you may interfere with the PVE integrated solution.

One random(!) article describing an as-simple-as-possible approach, just as an example: https://blog.ip2location.com/knowledge-base/how-to-block-ip-addresses-from-a-country-using-ipset/

Good luck!
Click to expand...


It is neither feasible nor efficient to move the filtering to the network perimeter.

Our infrastructure hosts thousands of virtual machines with specific firewall policies applied directly to the VM interfaces: multicast/broadcast control, port 25 blocking, and other per-VM rules. Replicating this at the perimeter would mean tens of thousands of rules, making it imposible to maintain:

  • Customer autonomy: each customer manages their own rules for their VMs. Centralizing this at the network level would break that model and create a bottleneck.

  • Policy portability: when a VM is moved to another host or segment, its rules move with it. If the rules were located in the network, devices would need to be reconfigured every time.

  • Scalability and governance: hypervisor-integrated firewalls are designed for this level of granularity; perimeter firewalls are not.

For all these reasons, we reserve the network/perimeter layer for global policies such as DDoS protection, anti-spoofing, basic access lists, and general compliance, but not VM-level rules where each user is free to apply their own filters.

There is a request to implement GEO and ASN filtering. Unfortunately, it has not been implemented yet, but I confirm that it is necessary.
You can see it here: https://bugzilla.proxmox.com/show_bug.cgi?id=5262

In my opinion, Proxmox should provide native integration for this and maintain the geo-ip-set and asn-ip-set lists as packages in the APT repository.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back