Managing firewall rules in Proxmox VE becomes exponentially harder as your infrastructure grows. When you need to block or allow traffic from entire organizations, cloud providers, or known bad actors, you face a simple problem with no simple solution. These organizations do not own neat, single IP blocks. They control thousands of fragmented network prefixes scattered across the routing table. Adding them manually creates bloated, slow firewalls that become obsolete within weeks. We built a tool to solve this problem. Today, we are open-sourcing PVE-SecGroup, an automated firewall object manager that turns Autonomous System Numbers into dynamic, self-updating security groups for Proxmox VE.

The Problem: Manual IP Management Does Not Scale

Consider a real-world scenario we encountered while managing production servers for clients. A specific hosting provider became a persistent source of scanning traffic and brute-force attempts. The solution seemed straightforward: block their IP ranges in the Proxmox firewall. The reality was far more complex. This provider operated under AS216071 and controlled hundreds of disjointed network prefixes. Manually adding each prefix as a firewall rule was tedious. Worse, these ranges change constantly as providers acquire or release IP space. Within a month, our carefully built blocklist was already incomplete and outdated.

This scenario repeats across every production environment. You need to whitelist traffic from your CDN provider. You need to block entire countries for compliance. You need to restrict API access to known partner networks. Every requirement translates into hundreds or thousands of individual firewall rules that must be maintained manually. Performance degrades as rule count increases. Human error becomes inevitable. Security drift becomes guaranteed.

What is PVE-SecGroup?

PVE-SecGroup is a Bash script that automates the creation and maintenance of Proxmox IPSet groups based on Autonomous System Numbers. An ASN is a unique identifier assigned to organizations that control blocks of internet routing, such as ISPs, cloud providers, universities, or large enterprises. Instead of tracking individual IP prefixes, you define security groups by ASN. The script queries the global BGP routing table, fetches all current prefixes for those ASNs, aggregates them into optimized supernets, and updates your Proxmox firewall automatically.

The tool runs as a scheduled job. Every night, it checks for routing changes, recalculates the optimal firewall rules, and applies updates atomically. Your firewall rules stay current without manual intervention. Your rule count stays minimal through intelligent aggregation. Your security posture adapts automatically to the constantly shifting internet routing table.

How PVE-SecGroup Works

The script follows a simple, reliable workflow designed for production stability. First, it loads your configuration file where you have defined target security groups mapped to specific ASNs. For each group, it queries the routing table using bgpq4, a specialized tool for BGP prefix lookups. The tool returns all IP prefixes currently announced by that ASN. PVE-SecGroup then aggregates these prefixes mathematically, merging adjacent networks into larger supernets wherever possible.

Here is where the atomic update approach becomes critical. The script does not modify your live firewall configuration directly. Instead, it builds a complete new configuration in a working file. Only after the entire new configuration is generated and validated does it replace the live configuration with a single atomic file operation. This ensures there is never a moment when your firewall is in a partially updated or broken state. Before any changes are applied, the script automatically creates a timestamped backup of your existing configuration. If something goes wrong, you have an immediate rollback path.

de># Example workflow when the script runs:

[2025-12-07 02:00:01] Starting Firewall Update Sequence...
[2025-12-07 02:00:01] Loaded configuration from: /etc/pve-secgroup.conf
[2025-12-07 02:00:01] Backup created at /etc/pve/firewall/backups/cluster.fw.1733540401.bak
[2025-12-07 02:00:02] Processing Group: [servers-tech-fzco] | ASNs: AS216071
[2025-12-07 02:00:03]   -> Fetched 42 aggregated prefixes.
[2025-12-07 02:00:03]   -> Group [servers-tech-fzco] updated in working config.
[2025-12-07 02:00:03] All groups processed. Configuration applied to /etc/pve/firewall/cluster.fw
[2025-12-07 02:00:04] Firewall service restarted successfully
[2025-12-07 02:00:04] Update sequence completed.

The Power of BGP Aggregation

The performance advantage of PVE-SecGroup comes from prefix aggregation. When an organization owns many small, adjacent IP blocks, bgpq4 can mathematically combine them into larger supernets. For example, if an ISP owns 256 consecutive /24 networks, those 256 individual firewall rules can be replaced with a single /16 rule that covers the exact same address space. Your firewall now checks one rule instead of 256. Processing overhead drops dramatically. Packet filtering becomes faster. Memory consumption decreases.

In production environments we manage, this aggregation typically reduces rule count by 85-95% compared to naive individual prefix listing. A security group that would require 1,200 individual rules becomes 40-60 aggregated supernets. The firewall performs the same security function with a fraction of the computational cost.

Configuration is Simple

The configuration file uses straightforward Bash syntax. You define target groups as an associative array mapping group names to space-separated lists of ASNs. You can configure whether blocked traffic should be rejected with an ICMP response or silently dropped.

de># /etc/pve-secgroup.conf

# Rule Action: REJECT or DROP
RULE_ACTION="REJECT" 

# Define Groups
declare -A TARGET_GROUPS

# Block a specific problematic hosting provider
TARGET_GROUPS["servers-tech-fzco"]="AS216071"

# Whitelist trusted CDN providers (Cloudflare and Google)
TARGET_GROUPS["trusted-cdn"]="AS13335 AS15169"

# Block an entire ISP known for abuse
TARGET_GROUPS["blocked-isp"]="AS12345"

Each group becomes an IPSet in your Proxmox firewall. You then reference these IPSets in your firewall rules just like any other IP address or network. The difference is that these IPSets update themselves automatically every night based on current BGP routing data.

Installation and Setup

Installing PVE-SecGroup requires only a few commands. The tool depends on bgpq4 for BGP lookups, which is available in standard Debian repositories.

de># Install dependencies
apt-get update && apt-get install bgpq4

# Clone the repository
git clone https://github.com/ENGINYRING/PVE-SecGroup.git
cd PVE-SecGroup

# Install to system directories
cp pve-secgroup.sh /usr/local/bin/
cp pve-secgroup.conf /etc/
chmod +x /usr/local/bin/pve-secgroup.sh

# Edit configuration to define your groups
nano /etc/pve-secgroup.conf

# Test the script manually
/usr/local/bin/pve-secgroup.sh

After verifying the script works correctly, add it to cron for daily automatic updates.

de># Add to crontab
crontab -e

# Update firewall groups daily at 2 AM
0 2 * * * /usr/local/bin/pve-secgroup.sh >/dev/null 2>&1

Real-World Use Cases

We have deployed PVE-SecGroup across multiple client environments to solve specific security and access control challenges. Here are scenarios where ASN-based firewall management provides immediate value.

  • Blocking Persistent Attack Sources: When a specific hosting provider becomes a consistent source of brute-force attempts or scanning traffic, blocking their entire ASN eliminates the problem at the source. The firewall automatically tracks their IP space as it changes, maintaining protection without manual updates.
  • Geofencing for Compliance: Certain regulatory frameworks require restricting access to specific countries. By creating IPSets for the major ISPs and hosting providers in a country, you can build an effective geographic firewall that updates itself as providers acquire new address space.
  • Partner Network Whitelisting: When integrating with third-party APIs or services, you can restrict inbound connections to only their known ASNs. This reduces your attack surface significantly compared to allowing connections from anywhere.
  • CDN and DDoS Protection Coordination: For applications behind CDNs like Cloudflare or Fastly, you can create an allow-list IPSet for the CDN provider's ASN and then reject all other direct traffic. This forces attackers to go through the CDN's protection layer.

Safety First: Understanding the Risks

Automated firewall changes are powerful but carry risk. An incorrect ASN configuration can lock you out of your own server. Before deploying PVE-SecGroup in production, ensure you have out-of-band access to your Proxmox host through IPMI, KVM, or a datacenter console. Test your configuration thoroughly in a non-production environment first. Always verify that your management IP address is explicitly whitelisted before applying broad blocking rules.

The script creates automatic backups before every run, but you should also maintain your own configuration backups independently. Understand what each ASN controls before adding it to a security group. A misconfigured whitelist can accidentally block critical services. A misconfigured blocklist can accidentally block your own infrastructure if your hosting provider shares an ASN with other customers.

Why We Are Open-Sourcing This Tool

PVE-SecGroup was born from a real operational need in our managed hosting practice at ENGINYRING. We built it to solve a problem we encountered repeatedly: maintaining accurate, performant firewall rules at scale. The tool has proven reliable in production environments across multiple client deployments. By releasing it under the MIT license, we are contributing back to the Proxmox and open-source communities that make our work possible.

This tool represents our approach to infrastructure management: automate repetitive tasks, eliminate human error, and build systems that stay correct over time without constant manual intervention. While PVE-SecGroup is a powerful addition to any sysadmin's toolkit, implementing a complete security strategy involves more than firewall automation. Our managed VPS services incorporate this level of automation as part of a broader security posture that includes monitoring, patching, intrusion detection, and expert support.

Get Started

The complete source code, documentation, and example configurations are available on GitHub at github.com/ENGINYRING/PVE-SecGroup. The tool is released under the MIT license, free to use, modify, and distribute. We welcome contributions, bug reports, and feature requests from the community. If you encounter issues or have questions about implementation, open an issue on the repository.

For organizations that prefer to focus on their core business rather than infrastructure management, ENGINYRING offers managed Proxmox environments where tools like PVE-SecGroup are deployed and maintained as part of our service. Explore our Virtual Servers offerings to see how we can bring this level of automation and expertise to your infrastructure.

Source & Attribution

This article is based on original data belonging to ENGINYRING.COM blog. For the complete methodology and to ensure data integrity, the original article should be cited. The canonical source is available at: Automate Proxmox Firewall Rules with ASN-Based Security Groups.