DEV Community: Mateo Rivera

Why I Stopped Relying on WAF Alone (And Added an API Firewall)

Mateo Rivera — Thu, 30 Apr 2026 01:03:28 +0000

A couple of years ago, I sat through a post‑mortem that changed how I think about application security. We had a WAF in place—properly configured, signatures up to date, running in reverse proxy mode. Still, an attacker managed to walk right through. They just found an internal API endpoint that wasn’t properly protected and started pulling data that should have never been accessible.

A WAF is great at stopping the noisy, obvious attacks, but it has a blind spot. It doesn’t really understand your API’s business logic, and it won’t stop someone who’s playing by the rules of HTTP but breaking the rules of your application.

Today, web applications and APIs are the main entry points for almost any business. Transactions, customer data, partner integrations—everything flows through them. And as the number of services grows, so does the attack surface. What used to be mass automated scans is now giving way to something more subtle: carefully crafted requests that look legitimate but exploit flaws in how your API handles authorization or business logic.

I’ve seen this trend play out in real incidents. According to recent industry reports, API‑related attacks have skyrocketed—some sources cite a 630% increase in 2024 alone, and a huge chunk of corporate applications carry API vulnerabilities that traditional web filters miss.

That’s why, over the past year, I’ve moved to a two‑layer approach: a WAF at the front door, and an API Firewall that sits closer to the actual services. They’re not redundant; they cover different things. In this post, I’ll walk you through how I think about both, why they work better together, and what I’ve learned from running them in production.

TL;DR

A WAF alone won’t protect your APIs—it’s built for web forms and HTTP, not business logic.
API attacks are growing fast; I’ve seen BOLA, mass assignment, and schema abuse slip right past a WAF.
An API Firewall uses a positive (allowlist) model: if the request doesn’t match your spec, it’s blocked.
Running both creates a two‑layer defense: WAF catches the noisy web attacks, API Firewall handles the subtle API‑layer abuse.
Track incident trends, false positives, and MTTR—not just how many requests you block.
Yes, maintaining specs takes work, but it’s cheaper than cleaning up a breach.

What a WAF Actually Does (And Where It Falls Short)

If you’ve ever deployed a WAF, you know it’s basically a gatekeeper that sits between the internet and your application. It inspects every incoming HTTP request—headers, parameters, the body, even the context—and decides whether to let it through or drop it on the spot.
A traditional firewall works at lower levels: IP addresses, ports, protocols. It’s great for segmenting networks or blocking traffic from a known bad IP. But a WAF operates at the application layer. It understands HTTP, and that’s its superpower. For example, a firewall in a platform like BILLmanager lets you implement classic network screening—blocking unwanted traffic based on protocol, source IP, and destination address.

I’ve run WAFs in a few different ways depending on the infrastructure.

The most common setup is reverse proxy mode: all traffic hits the WAF first, gets inspected, and only then is forwarded to the backend. It gives you centralized control, but you do take a latency hit—though in practice, it’s usually negligible if you size things right. Transparent proxy is another option; the WAF doesn’t change the destination address, so the client feels like it’s talking directly to the server. Bridge mode is a more low‑level option—it sits inline at the link layer—and passive mode just gets a copy of traffic for analysis, which is fine for monitoring but won’t block anything.

In my experience, reverse proxy strikes the best balance for most setups unless you have strict latency requirements or legacy constraints.

How It Decides What to Block

Under the hood, a WAF uses a mix of techniques. The oldest is signature‑based detection: it looks for known attack patterns—SQL injection strings, XSS payloads, that kind of thing. This is fast and effective for known threats, but it’s a cat‑and‑mouse game. Attackers tweak their payloads, and if your signatures aren’t constantly updated, things slip through.

Behavioral analysis is a step up. The WAF learns what normal traffic looks like for your application—typical request rates, common parameters, expected user journeys—and flags anything that deviates. It’s more flexible, but it takes time to tune. I’ve spent weeks adjusting thresholds to avoid false positives that would otherwise block legitimate users.

Some modern WAFs also use machine learning models to detect anomalies that don’t match any known signature. When it works, it’s impressive. But I’ve seen it go wrong when the training data is noisy or the model doesn’t understand the application’s actual behavior. It’s not a magic bullet.

In practice, I rely on all three: signatures for the low‑hanging fruit, behavioral rules for weird patterns, and ML as a catch-all—but always with manual oversight.

Once the WAF makes a decision, it can do a few things: block the request outright, drop the source IP into a quarantine list, or even sanitize the request (strip out malicious parts) and forward it. It’s a lot like an antivirus, but for web traffic. A good WAF also integrates with other tools—SIEM, identity systems, maybe an anti‑fraud service.

Before putting any WAF into production, I run a few sanity checks. Functional tests to make sure it doesn’t break legitimate traffic, load tests to see how it behaves under peak traffic, and failover tests because the last thing you want is a WAF outage taking down your app. But the most interesting tests are the red‑team style ones: I try to bypass it with obfuscated payloads, or see if it catches subtle API abuse. That’s often where you find the gaps—and why I eventually added an API Firewall to the mix.

The Missing Piece—API Firewall

APIs are tightly coupled with business logic. They process sensitive data and are often exposed to the outside world. Any mistake in an API can be extremely costly.

Industry data shows a sharp rise in attacks targeting APIs.

40,000+ API incidents observed in H1 2025 across 4,000+ environments, 44% of advanced bot activity now targets APIs.
87% of surveyed organizations reported experiencing an API-related security incident in 2025, the average number of daily API attacks rose 113% year over year.

An API Firewall is designed specifically to protect APIs. It inspects every incoming call, evaluating its structure, frequency, context, and compliance with the security policy.

Unlike solutions built for general web traffic, an API Firewall understands application‑layer protocols—REST, SOAP, GraphQL, gRPC, JSON‑RPC, and others. It doesn’t just look at headers; it analyzes the request body, schema, data types, parameters, and even client behavior. This makes it possible to catch attacks that slip past classic filters: BOLA, mass assignment, schema poisoning, and more.
So if an API Firewall is so good, why keep the WAF? Because they cover different threats. The WAF catches SQL injection attempts, XSS, and other classic web attacks that still come in through forms and front‑end endpoints. The API Firewall catches the more subtle, logic‑level abuse that targets the service layer. Running both gives you two layers of defense: the WAF filters the noise, and the API Firewall ensures what’s left still plays by the rules.

WAF + API Firewall: Why I Run Both

Let me give you a concrete example. Imagine you have an e‑commerce site. There’s a web frontend for desktop users and a mobile app that talks directly to APIs.

When an attacker tries to inject SQL through a search box on the website, the WAF sitting in front of the web server spots the malicious pattern and blocks it. Classic. WAF earns its keep.
But what happens when the attack comes through the mobile app? Say someone discovers they can call an API endpoint like /api/v2/payments without proper authorization and start pulling transaction data. The WAF sees an HTTPS request—nothing obviously malicious. No SQL, no XSS. It passes.

This is where the API Firewall steps in. It checks whether that endpoint is supposed to be accessible, whether the request schema matches what the API expects, and whether the user token has the right permissions. If anything’s off, it blocks the call. Data stays safe.

Different Focus Areas

WAF and API Firewall operate at different levels. Here’s how I think about the split:

	WAF	API Firewall
What it understands	HTTP, web forms, URLs	REST, GraphQL, gRPC, others
What it blocks	SQL injection, XSS, known exploits	BOLA, mass assignment, schema violations, rate abuse
Best at protecting	Frontend apps, traditional websites	APIs, microservices, mobile backends
Blind spots	Business logic, API-specific flaws	XSS, CSRF, classic web attacks

If you only run a WAF, your APIs are essentially unprotected against the kinds of attacks that exploit business logic. If you only run an API Firewall, your frontend forms are sitting ducks for injection attacks.

Modern applications aren’t just plain HTML forms anymore. I’m seeing more WebSocket connections for real‑time features, gRPC for internal microservices, and GraphQL endpoints that aggregate data from multiple sources. These technologies speed up development, but they also open new attack surfaces that traditional WAFs weren’t designed for. That’s why the two need to work together—not just coexist, but actually share context.

Two Ways to Think About Blocking

When I started combining WAF and API Firewall, I realized I was actually using two fundamentally different security models. Understanding the difference helped me tune each tool for what it does best.

Negative Model (Denylist)

This is the classic WAF approach. The rule is simple: everything is allowed unless it matches a known bad pattern. You maintain a list of signatures for SQL injection, XSS, brute‑force attempts, and so on. As long as a request doesn’t trip any of those rules, it gets through.

When I use it: For the web frontend—the public‑facing site where traffic is diverse and attackers throw all kinds of exploits. The negative model covers a broad range of threats without me having to specify exactly what good traffic should look like.
What I’ve learned: It’s quick to set up, but it’s only as good as your signature database. If you miss an update, or if the attacker uses a variant that isn’t yet in the rules, you’re exposed. Also, false positives can be annoying—legitimate users sometimes trigger rules because they typed something that looks like an attack. Tuning it takes time.

Positive Model (Allowlist)

This is the philosophy I use with the API Firewall. Instead of listing what’s bad, I define exactly what’s allowed. The API Firewall validates each request against a strict specification. Anything that doesn’t match is rejected.

Why I like it for APIs: Once you have a solid spec, the positive model is incredibly precise. It blocks requests that have extra parameters, wrong data types, or call endpoints that don’t exist. It also makes it trivial to enforce rate limits per endpoint, because the rule is “this client can call this path at this frequency.”
The catch: You need an up‑to‑date spec. If your API documentation lags behind the actual code, the positive model will start blocking legitimate traffic.

For the frontend applications, I stick with a WAF in negative model. It’s the right tool for catching the spray‑and‑pray attacks that still hit every public‑facing site.

For the APIs—especially those handling payments, user data, or core business logic—I use the API Firewall with a positive model. It gives me the confidence that even if an attacker figures out the endpoint names, they still can’t send malformed requests or abuse authorization.

When I run both together, I get the best of both worlds. The WAF blocks the noisy stuff; the API Firewall enforces strict contracts. I’ve stopped thinking of them as competing products and started treating them as complementary layers.

How I Measure Whether This Tandem Is Actually Working

Eventually, I settled on a few metrics that actually tell me whether the setup is improving security without breaking the user experience.

Incident Trends
This is the obvious one, but I look at it in a specific way. Instead of counting all blocked requests, I track successful attacks that reached the application. When I first added the API Firewall, that number dropped by about 80% over two months. Not because the WAF got worse, but because the API Firewall caught the stuff the WAF wasn’t designed to see.
MTTR (Mean Time to Respond)
When something does slip through, I measure how long it takes to detect and contain. With both layers feeding into a centralized log (SIEM), I’ve cut my MTTR roughly in half. The API Firewall provides structured data about which endpoint was hit, what the payload looked like, and whether the token was valid. That context saves hours of digging through WAF logs.
False Positives
False positives are the silent killer of security tools. If a WAF blocks a legitimate user, you lose trust. If an API Firewall rejects a valid call because the spec is outdated, someone will eventually ask to “just turn it off.”

I track false positive rates separately for each layer. For the WAF, I monitor how many requests get blocked that later turn out to be legitimate (usually from support tickets or user complaints). For the API Firewall, I look at rejected calls that match a known, authorized client. If the rate goes above 0.5% on either, I dig in.

Attack stop ratio A more subtle metric I’ve started tracking is attack stop ratio—how many attacks are stopped by the WAF versus how many reach the API Firewall.

I’ve aggregated all of this into a simple dashboard—nothing fancy, just a few graphs and a weekly summary. It shows trends over months, not just real‑time spikes. That way I can see if a new API deployment introduced more false positives, or if a signature update actually reduced incident rates.

The point isn’t to hit arbitrary numbers. It’s to know, with data, whether the two layers are working together or just adding complexity. So far, the tandem has paid off, but only because I keep an eye on these metrics and tune accordingly.

Layered Defense Isn’t Just a Buzzword

After running this tandem for over a year now, I’ve come to see it as less of a “nice to have” and more of a necessity. The days when you could put a WAF at the edge and call it done are over. Modern applications are too distributed, and APIs have become the primary way data moves between services and clients.

The WAF is my outer perimeter. It handles the noise—the automated scans, the injection attempts, the obvious probes. It keeps the attack surface manageable. The API Firewall understands the contracts my services expect, enforces them, and stops the requests that look perfectly fine to a generic HTTP filter but violate how my application is supposed to behave.

When they work together, they cover both ends of the spectrum: the technical exploits and the logic‑level abuse.

What I’ve Learned

If I had to distill this into practical takeaways:

Don’t assume your WAF sees your APIs. Most WAFs were built for web forms and HTML. If you expose GraphQL, gRPC, or even REST with complex JSON schemas, you need something that speaks those protocols.
Positive model for APIs is a game changer. It requires maintaining specs, but the precision it gives you is worth the overhead. I’d rather update an OpenAPI file than chase a data breach.
Metrics matter. I track false positives, incident trends, and layer efficiency. It helps me tune without breaking things.
One tool won’t cover everything. I tried both extremes: WAF alone, then API Firewall alone. Both left gaps. The combination is what actually moved the needle.

What About You?

I’m curious how others are handling this. Are you still running just a WAF? Have you added API‑specific protection? What’s been your experience with false positives or deployment complexity?

If you’re working with microservices, mobile backends, or anything that exposes APIs to the outside world, I’d love to hear what your stack looks like. Drop a comment—I’m always looking to learn from how other teams solve these problems.

How to Customize the Service Catalog in BILLmanager

Mateo Rivera — Sat, 27 Sep 2025 23:32:49 +0000

Many providers offer similar services at comparable prices — for instance, nearly identical VPS configurations that cost about the same. Yet, some companies make it easy for customers to find the right plan and complete their order, while others leave users confused during the selection process, causing them to leave without buying anything.

The issue usually isn't the services themselves, but how they're presented. Even small differences in how a service catalog is organized can significantly impact customer behavior.
BILLmanager lets you do more than just list your services; it allows you to structure them so that customers can:

Understand the differences between plans at a glance,
See all available options exactly when they need them,
Quickly assemble the ideal package of services.

We’ve previously covered how the BILLmanager service catalog works and why a well-thought-out "storefront" reduces the load on your support team, helps customers choose and order services faster, and enables providers to test new monetization ideas more quickly.

In this article, we’ll break down how to configure the service catalog display, set up plan grouping and filtering, and make your hosting services clear and visible to users.

Service Catalog Display

In BILLmanager, you can choose the best way to present your services — either as a classic list or in a modern card-based format.

How to configure:
This setting can be adjusted individually for each product type. Simply select the desired option in the "Tariff plan order form" section.

Plan and Product Type Icons

Visual design helps customers navigate your catalog. In BILLmanager, you can upload custom icons for service plans as well as for entire product types.

How to configure:

Go to edit a tariff plan or product type.
In the "Service order configuration" section, upload an image in the optimal resolution.
Configure the display parameters.

Grouping Tariffs

When you have a large number of service plans, grouping them by specific characteristics (filter groups) can be extremely helpful. For instance, this allows you to organize plans based on technical parameters. This gives potential customers the ability to filter plans by the criteria that matter most to them and quickly select the right service. A single plan can belong to multiple groups simultaneously.

Additionally, filter values can be used as tags, which can be color-coded for emphasis.

How to configure:

Go to the "Filter Groups" section.
Create a new group and configure its parameters.
For the created group, select "Values" → "Add" and define the necessary parameters.
Select a value, click the "Tariff", and assign the desired plans using the "Enable" and "Disable" buttons.

Filtering Tariffs
In BILLmanager, you can set up an intuitive system for logically categorizing your service plans, helping customers quickly find the right services based on key parameters. This feature is especially useful when a single product type contains many variants with different specifications. You can use it to highlight plans with specific technical characteristics, like 2 CPUs, or filter them by name.

Once configured, the left-hand menu in the "Products/Services" section will be structured as follows:
— Product Type (Level 1)
— — Product Subtype (Level 2)

When a user navigates to a Product Subtype, they will see all the plans assigned to that subtype.

How to configure:

To set up a subtype, go to Products → Product Types → select a type → the Subtypes button. Click the “New” button to add a subtype.
Activate the required tariff for this subtype. Go to Products → Product types → select a type → “Subtypes” button → select a subtype → “Tariffs” button → select a tariff → “On” button.

Adding Text Descriptions

In BILLmanager, you can create detailed plan descriptions to help customers make informed decisions. These can include both technical specifications and marketing information.

How to configure:

Enter your text description when creating or editing a tariff plan.
By default, BILLmanager will collapse long descriptions, showing only the first three lines of text.
To make descriptions always display in full, go to Product Types → Tariff plan order form settings and enable the "Disclose description in the order" option. This is useful if you want customers to see all plan details immediately before purchase.

Displaying Parameters

In BILLmanager, you have flexible control over how customers see the available add-ons for each service plan. This helps prevent interface clutter and focuses attention on the most important options.
By default, a plan's card displays all available add-ons: six are shown directly on the card, while the rest appear after clicking the "Show more" link. You can adjust the number of add-ons displayed.

How to configure:

Go to Tariff Plans → Options.
Select the desired add-ons and click "Edit".
In the "Service order configuration" section, disable the "Hide on the tariff card" option.

Number of Displayed Service Plans

In BILLmanager, you can choose how many service plan options a customer sees at once when browsing the catalog. This is especially useful for providers with a large catalogue of services.

By default, three plan cards are displayed, but you can configure this number to fit your needs.

How to configure:

Locate the configuration file. By default, it is located at /usr/local/mgr5/etc/billmgr.conf.
In the configuration file, find the PricelistPerItemtype parameter.
Set this parameter to your desired value.

Plan Prioritization

To promote specific products and services, BILLmanager allows you to manually control the display order of service plans and add-ons using a priority-based sorting feature.

Plans with a higher priority are automatically moved to the top of the list. This function is available for both main service plans and add-ons.

How to configure:

Open the editing form for the service plan.
In the "Service order configuration" section, in the "Sorting" field enter the desired numeric value. The lower the number, the higher the tariff plan will appear in the list.

A well-configured service catalog is more than just a list of plans—it's a powerful tool for increasing sales and reducing the load on your support team. With BILLmanager, you can:

Flexibly customize display using cards and filters,
Guide customer attention effectively,
Offer relevant services and useful add-ons.

Want to see how it works in practice? 👉 Try for Free

How to Customize the Service Catalog in BILLmanager

Mateo Rivera — Sat, 27 Sep 2025 20:44:39 +0000

The issue usually isn't the services themselves, but how they're presented. Even small differences in how a service catalog is organized can significantly impact customer behavior.

BILLmanager lets you do more than just list your services; it allows you to structure them so that customers can:

Understand the differences between plans at a glance,
See all available options exactly when they need them,
Quickly assemble the ideal package of services.

In this article, we’ll break down how to configure the service catalog display, set up plan grouping and filtering, and make your hosting services clear and visible to users.

Service Catalog Display

In BILLmanager, you can choose the best way to present your services — either as a classic list or in a modern card-based format.

How to configure:
This setting can be adjusted individually for each product type. Simply select the desired option in the "Tariff plan order form" section.

Plan and Product Type Icons

Visual design helps customers navigate your catalog. In BILLmanager, you can upload custom icons for service plans as well as for entire product types.

How to configure:

Go to edit a tariff plan or product type.
In the "Service order configuration" section, upload an image in the optimal resolution.
Configure the display parameters.

Grouping Tariffs

Additionally, filter values can be used as tags, which can be color-coded for emphasis.

How to configure:

Go to the "Filter Groups" section.
Create a new group and configure its parameters.
For the created group, select "Values" → "Add" and define the necessary parameters.
Select a value, click the "Tariff", and assign the desired plans using the "Enable" and "Disable" buttons.

Filtering Tariffs

In BILLmanager, you can set up an intuitive system for logically categorizing your service plans, helping customers quickly find the right services based on key parameters. This feature is especially useful when a single product type contains many variants with different specifications. You can use it to highlight plans with specific technical characteristics, like 2 CPUs, or filter them by name.

Once configured, the left-hand menu in the "Products/Services" section will be structured as follows:
— Product Type (Level 1)
— — Product Subtype (Level 2)

When a user navigates to a Product Subtype, they will see all the plans assigned to that subtype.

How to configure:

To set up a subtype, go to Products → Product Types → select a type → the Subtypes button. Click the “New” button to add a subtype.
Activate the required tariff for this subtype. Go to Products → Product types → select a type → “Subtypes” button → select a subtype → “Tariffs” button → select a tariff → “On” button.

Adding Text Descriptions

In BILLmanager, you can create detailed plan descriptions to help customers make informed decisions. These can include both technical specifications and marketing information.

How to configure:

Enter your text description when creating or editing a tariff plan.
By default, BILLmanager will collapse long descriptions, showing only the first three lines of text.
To make descriptions always display in full, go to Product Types → Tariff plan order form settings and enable the "Disclose description in the order" option. This is useful if you want customers to see all plan details immediately before purchase.

Displaying Parameters

In BILLmanager, you have flexible control over how customers see the available add-ons for each service plan. This helps prevent interface clutter and focuses attention on the most important options.

By default, a plan's card displays all available add-ons: six are shown directly on the card, while the rest appear after clicking the "Show more" link. You can adjust the number of add-ons displayed.

How to configure:

Go to Tariff Plans → Options.
Select the desired add-ons and click "Edit".
In the "Service order configuration" section, disable the "Hide on the tariff card" option.

Number of Displayed Tariffs

In BILLmanager, you can choose how many service plan options a customer sees at once when browsing the catalog. This is especially useful for providers with a large portfolio of plans.
By default, three plan cards are displayed, but you can configure this number to fit your needs.

How to configure:

Locate the configuration file. By default, it is located at /usr/local/mgr5/etc/billmgr.conf.
In the configuration file, find the PricelistPerItemtype parameter.
Set this parameter to your desired value.

Tariff Prioritization

To promote specific products and services, BILLmanager allows you to manually control the display order of service plans and add-ons using a priority-based sorting feature.
Plans with a higher priority are automatically moved to the top of the list. This function is available for both main service plans and add-ons.

How to configure:

Open the editing form for the service plan.
In the "Service order configuration" section, in the "Sort" field enter the desired numeric value. The lower the number, the higher the tariff plan will appear in the list.

A well-configured service catalog is more than just a list of plans—it's a powerful tool for increasing sales and reducing the load on your support team. With BILLmanager, you can:

Flexibly customize display using cards and filters,
Guide customer attention effectively,
Offer relevant services and useful add-ons.

Want to see how it works in practice?
👉 Try for Free

How the Service Catalog Works in BILLmanager

Mateo Rivera — Sat, 27 Sep 2025 20:07:08 +0000

A service provider's product catalog is more than just a list of available services—it's a core monetization engine. Its structure determines whether a customer gets stuck at the selection stage, how often your support team gets questions about pricing plans, and how quickly you can test new hypotheses regarding your prices and bundled offers.

A well-designed catalog reduces the load on your support team, increases conversion rates, and allows for faster hypothesis testing.

In this article, I'll break down how the BILLmanager service catalog is built.

Unsplash, Janis Ringli

The Structure of the BILLmanager Service Catalog

The service catalog in BILLmanager is built as a flexible hierarchy designed to help customers easily find the solutions they need. It consists of several key components:

Product Types — the main service categories.
Product Subtypes — more detailed classifications within those categories.
Tariff Plans — pre-configured packages with fixed parameters and prices.
Tariff Bundles — collections of plans that can be offered as bundled solutions.
Add-ons — additional services or goods that can be attached to a main order.

Product Types

Product Types in BILLmanager are the foundational structure for classifying your services. They determine how tariff plans are grouped in the catalog and displayed to customers. Each tariff plan can belong to only one product type.

BILLmanager comes pre-configured with standard categories like Web Hosting, Virtual Private Servers (VPS), Dedicated Servers, Domains, SSL Certificates, and Third-Party Licenses. You can also create custom product types to match your specific service offerings, such as Cybersecurity or Cloud Storage.

Using product types helps customers find what they need faster, without having to sift through a massive, unsorted list of services. For the provider, it eliminates backend chaos—all services are automatically organized onto their own dedicated "shelves."

Product Subtypes

For more precise service classification, BILLmanager offers Product Subtypes. The rules for tariff plans work the same way here—each plan can belong to only one subtype.

Unlike product types, there are no pre-configured options for subtypes; the provider creates them independently based on their service structure. For example:

For the Virtual Private Servers (VPS) product type, you could create subtypes like Basic, Premium, and For Development.
For the Web Hosting type—Shared, WordPress-Optimized.

Using subtypes makes the catalog more user-friendly: customers immediately see specialized categories and spend less time choosing, while the provider gains a clear and structured system for managing their tariff plans.

Tariff Plans

A Tariff Plan in BILLmanager is a ready-made commercial offer with a fixed set of resources and a set price. It is the final unit a customer can select when ordering a service.

The parameters that make up a plan vary by service type. For instance, the set of characteristics for a VPS will differ from those for web hosting. In some cases, there is built-in flexibility—the customer can customize certain configuration parameters before placing their order.

The structure of a tariff plan includes add-ons:

Mandatory add-ons (e.g., a base amount of disk space for a VPS).
Optional add-ons (e.g., an additional IP address, backup services, etc.). Tariff plans allow you to standardize your offerings while providing the necessary flexibility for different service categories.

Tariff Bundles

Bundles in BILLmanager are a tool for combining multiple services into ready-made packaged deals. They allow customers to sign up for comprehensive solutions with a single click, while providers can increase the average order value through cross-selling.

Bundles allow you to set special pricing, either at a discounted rate or as a fixed package price. After payment, all services within the bundle are activated through the standard process—just as if they had been ordered individually.

For example, you can use a bundle to create a "Business Startup Kit" that includes everything needed for a quick launch—like a domain, web hosting, and an SSL certificate—or any other package you can think of.

Related products (Customers also buy)

Related products in BILLmanager are additional services that are automatically offered to a customer during the checkout process for their main order. They help increase the average order value and enhance the customer experience through timely, relevant recommendations.

When a tariff plan is added to the cart, the system suggests relevant related products (for example, when ordering a virtual server, it might suggest a domain or an SSL certificate). The customer can immediately add these needed services to their order without having to go back to the main catalog.

All these suggestions are configured by the administrator and displayed as clear, understandable options.

A well-organized service catalog in BILLmanager allows the provider to create comprehensive offerings, simplifies sales scaling through packaged deals, and increases the average order value via automated add-on suggestions. At the same time, the customer benefits from an intuitive service navigation system, the ability to choose either ready-made bundles or individual services, and complete transparency regarding the provider's offerings and pricing.

In the next article, I will cover the catalog customization capabilities in BILLmanager—how to choose its display mode, configure tariff plan grouping—and how these features reduce the time it takes to choose and order services.

How to Sell VPN as a SaaS Using VMmanager — Setup in 3 Steps

Mateo Rivera — Mon, 30 Jun 2025 20:47:14 +0000

With VMmanager, you can quickly create a new service for your customers by selling VPN servers using the SaaS model. The platform includes ready-made templates and tools to help you launch this service.

This enables you to easily and cost-effectively offer a higher-value product compared to traditional VPS/VDS rentals.

For customers, this means getting a fully configured VPN without having to administer the guest OS of the virtual machine. Potential clients for this service include individuals and businesses willing to pay for a secure, anonymous VPN solution.

VMmanager offers two popular VPN server implementations: OpenVPN and WireGuard. Choose the one that best suits your needs. You can also customize your own software as a service (SaaS) based on the existing templates. Below, I’ll explain how to set up a VPN for your customers.

Setting Up a VPN Service — A Step-by-Step Guide

A SaaS-based VPN is a virtual machine (VM) with pre-deployed software, that is installed automatically using scripts.
To configure the VPN service following this guide, you’ll need:

A cluster of nodes in the desired geographic location
VMmanager 6
BILLmanager (for service billing and managing user access to the installation script) Let’s get started!

Step 1: Create a New VM Configuration

For example: VPN-server-WG1

This configuration will be used later in BILLmanager to set up billing. Additionally, the VPN server installation script will only be available for this configuration. More information is provided below.

Step 2: Configure the VPN Script

Go to the "Scripts" section
Choose the OpenVPN or WireGuard VPN script
Click "Copy" to duplicate the script
A new window will open where you can modify the parameters of the copied script:

Enter the name of the script
Set access to "All"
Check the "Hide script contents" box (recommended to avoid exposing unnecessary technical details to clients and simplify service usage)
Add a filter to restrict execution to the previously created configuration (VPN-server-WG1). This ensures the script will only be available to VMs with this configuration.

Step 3: Configure Email Notifications

Complete the HTML template with your custom message in the same section to set up an email notification.

<div>
<img src="https://www.ispsystem.com/pictures/icon_wireguard_1.jpg" alt="Wireguard" style="width:33px;padding-right:5px; vertical-align: middle;">
<h1 style="display:inline; vertical-align: middle;">Your WireGuard server is ready</h1>
</div>
<div style="width: 600px">
<p style="margin-top: 10px;">To start using it, please:</p>
<ol style="padding-left:20px;">
<li>Download and install the client on your device:</li>
<div class="download" style="margin:10px 0 10px -15px;">
<a href="https://www.wireguard.com/install/"><img src="https://www.ispsystem.com/pictures/download-windows-linux.jpg" alt="windows" class="windows" style="width:194px;"></a>
<a href="https://play.google.com/store/apps/details?id=com.wireguard.android&amp;hl=ru&amp;gl=US"><img src="https://www.ispsystem.com/pictures/download-android.jpg" alt="android" class="android" style="width:137px;"></a>
<a href="https://apps.apple.com/ru/app/wireguard/id1441195209"><img src="https://www.ispsystem.com/pictures/download-apple.jpg" alt="ios" class="ios" style="width:137px;"></a>
</div>
<li style="margin-bottom: 10px;">Import the file attached to this email into WireGuard</li>
<li>Make a connection</li>
</ol>
</div>

Here’s how the WireGuard setup notification email will appear to your clients:

The BILLmanager integration uses the virtual machine template created in Step 1. This template is linked to a specific tariff plan that includes the service cost. You can configure the integration following the official documentation.

Customers who purchase this tariff can then run the VPN installation script on their virtual machine.

How Customers Order the VPN Service: WireGuard Example

The customer journey for ordering a VPN through BILLmanager is straightforward.

Ordering the VM: First, the customer selects a tariff plan linked to the VPN-server-WG1 configuration.
Script execution. After provisioning, the customer logs into VMmanager 6 and runs the pre-configured VPN installation script on their VM.
Email. Once the script has finished running, the customer receives an email containing setup instructions and a VPN configuration file. The email also includes download links for client apps that are pre-configured for all major operating systems, including Windows, macOS, Linux, Android, and iOS.

This workflow can be applied to other SaaS services. Just prepare an installation script for the additional software or use pre-built VMmanager templates.

How to build a flat L2 network between VMs and hardware in different locations

Mateo Rivera — Mon, 26 May 2025 00:33:48 +0000

Hello everyone! My name is Mateo. I'm a software developer and network engineer from Argentina.

At my company, we use a wide variety of technical solutions: open-source software, proprietary solutions, and many others. While there are many useful software product manuals available, official documentation does not always cover solving complex problems and corner cases. So I will be preparing useful articles and sharing my own experience in this field on my blog.

For now, I have chosen to focus on the products offered by ISPsystem: VMmanager and DCImanager. This article covers the flat networks workflow. I hope you enjoy reading and find the information useful!

If your infrastructure includes both VMs and physical servers, you may one day find that you need to connect them to the single network. L3 connectivity is not always the answer. And sometimes, you need to combine services into an L2 network.

For example, you have a platform installed on a virtual machine to manage your physical IT infrastructure. If all your hardware is located in one site and you have access to network equipment, you can solve the problem by configuring VLANs on switch ports and in the hypervisor.

But what if the servers and VMs are geographically distributed, and you don't have access to switches and routers in the data center? So, you will need to configure L2VPN between the sites.
Here's how you can solve this problem.

How it works

We’ll use VxLAN tunnels and the BGP EVPN dynamic routing protocol to connect two networks.

If you already have VMmanager, turn on the "Virtual Networks" technology for your cluster. VMmanager will set up the BGP FRR daemon on the cluster nodes and create VxLAN tunnels.
Here’s an example.

Let's assume we have a Juniper QFX5100 physical switch with VxLAN and BGP EVPN support. Let's connect a physical server to port xe-0/0/1.

VMmanager cluster consists of two nodes connected to a switch. Node 1 hosts a virtual machine that is connected to a virtual network. A physical server located at another site is connected to the Juniper QFX switch via port XE-0/0/1. A routable network is configured between the QFX switch and nodes 1 and 2.

The setup process

Configure the switch

Connect the QFX to the routable network so that the address on the lo0.0 interface is accessible from the VMmanager cluster nodes (in our example, this is 10.3.0.47).
Select the AS number to use. In this example it is 62200:

routing-options {
  router-id 10.3.0.47;
  autonomous-system 62200;
}

Configure VTEP:

switch-options {
  vtep-source-interface lo0.0;
  route-distinguisher 10.3.0.47:1;
  vrf-target target:62200:1;
}

Configure BGP and specify all nodes of your VMmanager cluster as neighbors:

protocols {
    bgp {
        group VMmanager {
            type internal;
            local-address 10.3.0.47;
            family evpn {
                signaling;
            }
            peer-as 62200;
            neighbor 172.31.33.2 {
                cluster 10.3.0.47;
            }
            neighbor 172.31.33.3 {
                cluster 10.3.0.47;
            }
        }
}

Set up VMmanager

In the cluster settings, turn on "Virtual Networks" and switch to Route Reflector mode.
Set the local autonomous system to 62200.
Add QFX 10.3.0.47 with autonomous system 62200 to the neighbors.

Let’s assume that johndoe@ispsystem.net is our default VMmanager user. Log in to the administrator user account and do the following:

Create a new virtual network: 192.168.10.0/24.
Create a new virtual machine in this virtual network.

After creating the VM, go to the “Network Settings” section and copy the VxLAN number. In our example, the interface is connected to vxbr1194142, which means that our VNI will be 1194142.

Return to the QFX configuration

Add the EVPN protocol settings:

protocols {
    evpn {
        vni-options {
            vni 1194142 {
                vrf-target target:62200:1194142;
            }
        }
        encapsulation vxlan;
        multicast-mode ingress-replication;
        extended-vni-list all;
    }
}

Please note: it is crucial to specify vrf-target = target:ASN:VNI, otherwise the routes will not be established and there will be no connectivity.

Create a VLAN:

vlans {
    test {
        vlan-id 100;
        vxlan {
            vni 1194142;
            ingress-node-replication;
        }
    }
}

Connect the following port to this VLAN:

interfaces {
    xe-0/0/1 {
        ether-options {
            auto-negotiation;
        }
        unit 0 {
            family ethernet-switching {
                interface-mode access;
                vlan {
                    members test;
                }
            }
        }
    }
}

Done! Now the VM you created and the server are on the same flat network.

Troubleshooting

Let's check the connection on our server:

root> show evpn database
Instance: default-switch
VLAN  DomainId  MAC address        Active source                  Timestamp        IP address
     1194142    00:1e:67:ca:6d:a9  xe-0/0/1.0                     Mar 12 15:44:40  192.168.13.3
     1194142    52:54:00:6b:33:a6  172.31.33.2                    Mar 12 14:12:26

Also, let's check the connection on the VM Manager node. Run the vtysh command:

show evpn mac vni 1194142
Number of MACs (local and remote) known for this VNI: 2
Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy
MAC               Type   Flags Intf/Remote ES/VTEP            VLAN  Seq #'s
00:1e:67:ca:6d:a9 remote       10.3.0.47                            0/0
52:54:00:6b:33:a6 local        vm13706_vxlan0                       0/0

Other servers can be added to this network by simply assigning the VLAN to the appropriate port. In addition, we can create more virtual machines for the user in this VxLAN. They will all be inside the virtual network.

The result

We combined virtual machines and physical servers in different locations into a flat, non-routable L2 network. Now, we can manage physical servers through DCImanager or deploy a private network between virtual and physical servers to complete other tasks.

The most important feature of this approach is that it does not involve routing. With VxLAN, traffic is encapsulated and appears to external routers as UDP traffic between two points.

I hope this mini-tutorial was helpful and saved you some time. I plan to publish new tutorials on my blog, so stay tuned for updates and subscribe!