VesperAegis Firewall — Adaptive Network Security & Traffic Intelligence

Over the past few days, I have been working on something different from my usual penetration-testing labs.

Instead of only testing security controls, I wanted to understand what happens on the other side:

How is a firewall actually built?

That question led me to build VesperAegis Firewall, a Linux-based firewall project designed to provide rule management, traffic enforcement, monitoring, authentication, and a web-based management interface.

This started as part of my cybersecurity internship, but I decided to take the project beyond simply researching firewall technologies and actually build a working application around Linux's native firewall infrastructure.

The project is still evolving, and this article documents what I have actually built so far, how it is structured, how I am testing it, and what I plan to build next.

Why Build a Firewall?

During my research into firewall technologies, I spent time understanding how firewalls evolved from basic packet filtering to stateful inspection, NGFWs, cloud firewalls, and modern security platforms.

But theoretical understanding only gets you so far.

I wanted to answer questions such as:

• How does a firewall rule become an actual kernel-level enforcement rule?

• How should firewall policies be represented in an application?

• How can invalid or conflicting rules be detected before deployment?

• How should firewall configuration be stored?

• How should administrators interact with the firewall?

• How can traffic statistics and firewall events be monitored?

• How can an application safely control the underlying firewall?

Instead of building another theoretical architecture diagram, I decided to build a practical system.

That became VesperAegis.

Introducing VesperAegis

VesperAegis Firewall

Adaptive Network Security & Traffic Intelligence

The idea is relatively simple:

The application should provide the management and intelligence layer, while Linux should remain responsible for the actual packet enforcement.

I did not want to implement a firewall engine from scratch in Python.

Instead, the project uses nftables/Netfilter, which allows Linux to perform the actual network filtering.

The application sits above that enforcement layer.

The Core Architecture

The current architecture looks like this:

The important design decision here is the separation between application-level policy management and actual packet enforcement.

The Python application does not replace the Linux firewall subsystem.

This gives VesperAegis a clear responsibility boundary.

Why nftables?

One of the most important decisions was choosing the actual enforcement mechanism. I chose nftables/Netfilter because I wanted the project to operate on top of Linux's native packet-filtering infrastructure rather than attempting to simulate firewall behaviour inside Python.

A Python application displaying:

ALLOW TCP 192.168.50.10 → 192.168.60.20:80

doesn't make that traffic allowed by itself. The policy eventually needs to reach the actual enforcement layer. That's why nftables is central to the project.

Why Python?

Python is used as the primary application-development language.

The project has several components that benefit from Python:

• API development, Rule processing, Validation, Configuration management, Database interaction, Authentication logic, System integration, Testing, Operational scripts.

Python also makes it easier to iterate quickly while keeping the project understandable.

The goal wasn't to create an enormous codebase. The goal was to create something where I could understand how the components interact.

Why FastAPI?

The firewall needs an interface through which the dashboard and other clients can communicate with the backend.

For that layer, I chose FastAPI.

The REST API provides endpoints for operations such as:

• Firewall status, Rule management, Configuration, Logs, Traffic statistics, Authentication, System information.

This also gives the project a cleaner separation between the frontend and backend. The dashboard doesn't need to directly manipulate nftables. Instead, it communicates with the API.

Why SQLite?

I intentionally kept the database layer lightweight. VesperAegis uses SQLite for configuration and application state.

For this project, I don't need a large distributed database infrastructure.

SQLite is sufficient for storing information such as:

• Firewall rules, Rule configuration, Application state, Relevant event, information, Authentication-related application data

This keeps the project easy to deploy in a laboratory environment while still giving it a proper persistence layer.

Firewall Rule Management

One of the main components I wanted to build was proper rule management.

The application currently supports operations such as:

• Create rules, Edit rules, Delete rules, Enable rules, Disable rules, Configure priority, Configure protocols, Configure source/destination, addresses, Configure ports

A conceptual rule could look like:

action: allow
protocol: tcp
source: 192.168.50.10
destination: 192.168.60.20
destination_port: 80
enabled: true
priority: 10

The YAML representation is useful for making firewall policy readable and manageable. But before a rule reaches nftables, it should go through validation.

Rule Validation

This became one of the more interesting parts of the project. A firewall application shouldn't blindly accept every rule entered by an administrator.

VesperAegis currently performs validation for areas such as:

IP / CIDR validation

For example:

192.168.50.10
192.168.60.0/24

Port validation

The application checks whether port values fall within valid ranges and whether the rule structure is correct.

Protocol validation

Rules need to use supported protocols rather than arbitrary values.

Priority

Rules can have priorities so that policy ordering can be managed explicitly.

Detecting Conflicting Rules

Another feature I wanted to implement was rule conflict detection.

Consider:

Rule 1:
ALLOW TCP → 192.168.60.20:80

Rule 2:
DENY TCP → 192.168.60.20:80

Both rules target the same traffic. Without proper handling, administrators could create confusing policies and wonder why traffic behaves differently from what they expected. The application therefore attempts to identify problematic combinations before they become operational issues.

Rule Shadowing

A related problem is rule shadowing.

For example:

Rule 1:
DENY 192.168.60.0/24

Rule 2:
ALLOW 192.168.60.20

Depending on ordering and evaluation logic, the second rule may never become effective. This is an important firewall-management problem because a rule can look perfectly valid syntactically while being ineffective from a policy perspective.

VesperAegis therefore includes shadowing detection as part of its rule-analysis layer.

Security Warnings

The project also provides warnings for potentially dangerous or overly broad rules.

For example, administrators should be careful with policies equivalent to:

ALLOW
ANY
ANY
ANY

A rule can be syntactically valid while still being a poor security decision. This is where the application layer can provide value beyond simply passing configuration to nftables.

Authentication and Access Control

A firewall management interface itself is a security-sensitive application.

If an attacker can access the dashboard and modify firewall policy, the firewall becomes another attack surface. Because of that, authentication was included in the project.

The current implementation includes:

• Authentication, Session-based access control, Protected API access, Protected application pages, Administrator credential management, Password hashing using PBKDF2-SHA256.

The initial administrator account also requires a credential change rather than relying on permanent default credentials.

Dashboard and Monitoring

VesperAegis also includes a web dashboard.

The purpose of the dashboard isn't simply to make the project look nice.

It provides an operational interface for viewing things such as:

• Firewall status, Rules, Logs, Traffic statistics, System information, Configuration state.

The frontend is built using:

HTML
CSS
JavaScript

while communication with the backend happens through the FastAPI REST API.

Firewall Enforcement vs Logging vs Packet Capture

One distinction I specifically wanted to maintain in the architecture is that firewall enforcement, logging, statistics, and packet capture are not the same thing.

It would be incorrect to describe VesperAegis as storing every raw packet in SQLite.

That's not the design.

Instead:

                ┌───────────────┐
Traffic ───────→│   nftables    │
                └───────┬───────┘
                        │
                 Enforcement
                        │
                        ▼
                 Packet Counters
                        │
                        ▼
              Application Statistics

The application can record relevant firewall events and statistics.

For deeper packet-level investigation, tools such as:

tcpdump
Wireshark

can be used separately during testing. This separation keeps the database from becoming an unnecessary packet-storage system.

The Laboratory Network

The next important stage was moving from application testing toward real network testing. I built an isolated laboratory environment so that I could test forwarded traffic without mixing it with management traffic.

The current topology is:

The intended traffic path is:

Kali
  ↓
VesperAegis
  ↓
Protected Network
  ↓
Target

This isolation is important because I want to test actual forwarded traffic through the firewall, rather than simply testing rules against the firewall's own management traffic.

Testing From the Attacker Side

Kali will act as the attacker/testing machine. The protected network contains Ubuntu or intentionally vulnerable machines.

This allows me to test scenarios such as:

Kali
 ↓
Reconnaissance
 ↓
Firewall
 ↓
Protected Target

I can then modify firewall policies and observe how traffic behaviour changes.

For example:

ALLOW TCP/80

should produce different behaviour from:

DENY TCP/80

The important part isn't simply seeing a rule inside the dashboard.The objective is to verify that the actual network traffic is affected by the policy.

AI Is a Future Layer

The name Adaptive Network Security & Traffic Intelligence points toward something I want to explore later:

AI-assisted security.

But I deliberately did not make AI responsible for directly controlling nftables.

Potential future capabilities include:

• Risk scoring, Rule recommendations, Log summarization, Policy, explanation, Traffic anomaly analysis.

The architecture:

The important part is the human approval layer. I don't want a probabilistic model to directly modify firewall enforcement without oversight. AI can provide recommendations and analysis. The firewall should remain deterministic and controlled.

What Building a Firewall Taught Me

One of the biggest lessons from this project is that a firewall isn't just an ALLOW or DENY command.

There are several layers involved:

User Policy
    ↓
Application
    ↓
Validation
    ↓
Rule Engine
    ↓
Configuration
    ↓
nftables
    ↓
Netfilter
    ↓
Linux Kernel
    ↓
Network Interface
    ↓
Traffic

Every layer introduces its own engineering and security considerations. A mistake in the UI can become a bad policy. A mistake in validation can become an invalid rule. A mistake in rule translation can result in unexpected enforcement. And a mistake in authentication can potentially allow an attacker to control the entire security boundary. That makes firewall development a much more interesting engineering problem than I initially expected.

Final Thoughts

VesperAegis started with a simple question:

Why can't I build a firewalls and actually learn while building it?

The answer has been a much deeper engineering experience than I expected. I've had to think about Linux networking, nftables, APIs, databases, authentication, rule processing, network topology, testing, and the security of the management application itself.

The project is not an enterprise firewall, and I don't intend to present it as one.

It is a practical cybersecurity engineering project that I am building to understand how firewall systems work from the inside out.

Project

VesperAegis Firewall Adaptive Network Security & Traffic Intelligence

The project is being developed as part of my cybersecurity internship and is maintained as a practical learning and engineering project.

🔗 GitHub: VesperAegis Firewall

Disclaimer

VesperAegis is an independent cybersecurity engineering project developed for learning, research, and authorized laboratory testing. It should not be considered an enterprise-ready firewall or deployed in production without extensive security review, testing, hardening, and validation.

All network testing described in this article is intended for isolated and authorized laboratory environments.