Neurowall edition · ISPs, datacenters & hosting providers

NeuroWall Edge.
Built to sit
at the edge of
someone else's network.

Most firewalls protect one network: yours. NeuroWall Edge protects many networks at once — each belonging to someone else — from a single box you operate. It's the datacenter gateway deployment plus a self-service tenant API, packaged for ISPs, datacenters, and hosting providers.

FORWARD
Primary enforcement path
No DNAT
Routed public prefixes
3/4/5-tuple
Tenant-owned rules
404
On cross-tenant access, not 403
The deployment

A gateway for public prefixes, not just a box with a public IP.

Most firewall products assume they're protecting the host they're installed on, or a private LAN behind NAT. Neither assumption holds at datacenter scale.

01 · Topology
Routed public prefixes, not NAT

A datacenter or ISP gets one or more public prefixes routed to a gateway by its upstream. The gateway forwards traffic straight through to servers carrying real, routable public IPs — no DNAT, no port-forwarding gymnastics.

02 · Enforcement
Policy lives in the FORWARD path

Datacenter gateway mode enforces policy primarily via nftables in the FORWARD chain — WAN to servers, servers to WAN — with eBPF/XDP handling the fast-path blocklist and DDoS layer underneath it.

03 · Fit
A third deployment mode, not a retrofit

Datacenter gateway mode sits alongside NeuroWall's existing host-firewall and NAT gateway modes — built for the "routed public subnets behind a gateway" shape ISPs and datacenters actually run.

The customer-facing half

A tenant API, not a ticket queue.

A gateway only the provider can touch solves half the problem. The other half: what happens when the customer needs to react to an attack right now?

Provisioning

Name, subnet, API key

The provider provisions each customer as a tenant: a name, an assigned IP or subnet, and a per-tenant API key (X-Tenant-Key). From that point on, the tenant can create and delete their own rules the moment they need to — zero NOC involvement.

Scope

3/4/5-tuple block/allow rules — action, protocol, source_ip, port — scoped strictly to IPs the tenant actually owns.

Separation

A completely separate front door

Tenant authentication (X-Tenant-Key) and provider/admin authentication (JWT + role-based access) share no middleware, no context, no failure path. Handing a customer real-time control over their own rules never means handing them a foothold into anyone else's infrastructure, or the provider's own admin surface.

Customer Portal

A separate, standalone project with its own login and database consumes the tenant API — deliberately kept apart from NeuroWall's own admin/operator/viewer authentication.

Isolation guarantees

What that isolation actually guarantees, not just promises.

Why one edition, not two features

Neither half is much use without the other.

A fast gateway only the provider can operate still routes every "block this IP" request through the same 2am ticket queue. A slick self-service portal with nothing fast underneath it just moves the bottleneck from "waiting on support" to "waiting on the firewall to catch up."

Kernel-speed enforcement

For the traffic pattern datacenters and ISPs actually have — routed public prefixes, no DNAT, policy in the FORWARD path.

Immediately-effective self-service

For the customers living on top of it, with isolation strict enough that a provider can hand over control without inheriting new risk in return.

Who this is for

Infrastructure for other people, not just for yourself.

A datacenter with routed public prefixes. A hosting provider. An ISP handing customers their own IP space. If "please block this IP" is a recurring line item in your support queue, this is the edition built for exactly that shape of problem.