When ADC and firewall are managed separately, the security chain breaks.
In classic architectures the ADC lives on one device, the firewall on another, and routing and NAT rules exist in yet another operational layer. This separation looks tidy at first, but in production every change becomes a coordination problem. A new vService is opened and the firewall rule is forgotten. A DNAT changes and the route is not updated. A backend segment shifts and the FORWARD rule stays stale.
In multi-namespace or multi-tenant environments the problem grows larger. When each tenant has its own IP space, its own interfaces and its own NAT rules, a single global firewall table is not sufficient. The same CIDR can be used in different namespaces; in that case the firewall must also be separated by namespace.
Using a separate firewall device is not only an extra management burden — audit and failover also fragment. An operator cannot answer "who opened this traffic?", "which automatic rule came from which vService?" or "in which namespace is this DNAT active?" from a single panel. During an incident, ADC logs, firewall logs and routing state must be inspected separately.
Rule application safety is another problem. In traditional firewall rule sets, a single faulty line can cause the entire load operation to fail. In production the consequence is severe: correct rules are also not applied, traffic is interrupted or the security policy falls idle.
TR7 ADC treats the firewall as a natural part of the ADC: per-namespace rule sets, per-interface control, automatic ADC/GTM/NAT rules, DDoS directives, a test-apply pipeline and faulty-rule isolation are combined in a single management model.
Our approach
TR7's firewall approach is not a separate security device bolted on — it is an L3/L4 control layer embedded in the ADC's traffic, routing and namespace model.
Per-namespace firewall management
Each namespace has its own firewall manager. A rule inside one namespace does not touch traffic in another namespace. This model provides safe isolation in multi-tenant, overlapping-CIDR and separate-route-table scenarios.
Test → apply pipeline
New firewall content is tested first and then applied. If a line fails, the entire rule set is not cancelled — the faulty line is automatically disabled and the healthy rules are retried. This prevents a single error from dropping the entire rule set during a production change.
Parallel IPv4 and IPv6 rule sets
IPv4 and IPv6 rules are managed in separate files, with separate validation, in parallel. A failure in one IP family does not affect the other. On dual-stack services the security policy is applied consistently for both families.
Automatic firewall rules from ADC objects
When an ADC pool, L4 NAT, inline DNAT, GTM DNS redirection, management access or backend marker is configured, firewall rules can be generated automatically. Operators opening a vService do not need to remember the security side separately.
Capabilities
The Built-In Firewall combines classic L3/L4 control with ADC-native automatic rule generation, DDoS mitigation, quarantine, deterministic CGNAT and namespace isolation.
Per-namespace firewall isolation
Each namespace operates with an independent firewall rule set. A DNAT defined in Tenant A's namespace does not affect the same CIDR block in Tenant B. This structure provides the fundamental security separation for multi-tenant and overlapping IP space scenarios.
Deterministic CGNAT — subscriber traceability without a session log
Each subscriber gets a fixed, pre-calculated block of public ports, so identifying a subscriber from a public address and port is arithmetic — not a database lookup. The per-session logging RFC 6888 otherwise forces, which usually dominates the cost of a CGNAT deployment, disappears while legal traceability is preserved. ALGs for FTP, TFTP, SIP, PPTP and H.323 are included. Endpoint-independent filtering and hairpinning are outside this version's scope.
Separate IPv4 and IPv6 management
IPv4 and IPv6 rules are produced and applied as separate rule sets. In dual-stack services the IPv6 side is not forgotten later; allow, deny, forward, NAT and rate-limit controls can be written for both IP families.
Dual-stack NAT, NAT66 included — one rule, both address families
The same rule engine emits IPv4 and IPv6 rule sets from a single policy, so static SNAT, DNAT and one-to-one translation behave identically on an IPv6 network. Translation between IPv6 prefixes — NAT66 — is part of it, stated plainly because the term is usually assumed to be missing. There is no separate IPv6 configuration path and no rule that quietly applies to only one family, which is what stops an IPv6 rollout from becoming a second, half-remembered firewall.
Per-interface rule definition
Rules can be defined not only at namespace level but also at interface level. Different policies can be applied to the management interface, sync interface, tenant interface or service interface. This model controls traffic according to the actual ingress/egress point.
Allow, deny, forward and not-forward rules
Core firewall operations are managed in a single model. Permit, block, allow transit passage or exclude specific traffic from transit can all be defined in the INPUT and FORWARD chains.
DNAT and SNAT support
DNAT can be applied to redirect incoming traffic to a different destination IP; SNAT changes the source IP of outgoing traffic. Inline publishing, L4 service redirection and multi-backend-segment scenarios are managed with these rules.
GeoIP and country-based matching
Source IP matching can be performed against country sets. It is possible to allowlist certain countries, block specific countries or quickly drop high-risk regions during an attack. Set-based operation preserves performance at scale.
CIDR, MAC and negate matching
IP/CIDR, MAC address and "exclude" logic are supported. For example, an entire subnet can be blocked while specific IPs are exempted. This structure is used for both operational allowlists and temporary incident response rules.
Multi-port and port-range matching
Multiple ports or port ranges can be defined in a single rule. Broad or narrow access policies can be written for DNS, RADIUS, SIP, API and management ports.
20+ DDoS protection directives
Invalid packet drop, new TCP connection limit, total connection limit, UDP flood limit, DNS/NTP flood limit, TCP reset limit, fragment drop, suspicious MSS, LAND attack detection and zero-byte UDP blocking can all be enabled under a single policy.
Quarantine tables
Sources that exceed a threshold are added to temporary quarantine sets. When the quarantine period expires the entry is automatically removed. Whitelist sets can be excluded from quarantine rules so trusted sources are never accidentally affected.
Connection mark support for L4 persistence
Connection marks and recent lists can be used to bind specific client traffic to the same backend in L4 services. This is important for session continuity in UDP or port-range scenarios.
Automatic ADC/GTM/NAT rules
Automatic rule types are supported for permitting a service port when a pool is opened, generating L4 SNAT/DNAT, creating an inline DNAT rule, redirecting GTM DNS access or adding a local deny rule.
Faulty-rule isolation
When a line fails during rule set application, it is detected, commented out, and the remaining rules are retried. A single faulty rule cannot stop the entire firewall synchronization.
Log and audit support
Rules can be configured to produce log entries. Drop, allow, DNAT or quarantine behaviors can be included in the audit chain. After an incident, which rule affected which traffic can be traced.
Automatic protection for management and cluster-sync interfaces
Management and cluster sync traffic is handled specially by the system. Critical interfaces are protected with automatic allow behavior to prevent accidental loss of operational access.
Operational depth
The built-in firewall layer is not just a rule-writing screen — it works together with testing, synchronization, error isolation, automatic rule generation and namespace lifecycle management.
Config path and rule-set separation
IPv4 and IPv6 firewall content for each namespace is stored in separate configuration files. The last combined configuration is also retained, making change tracking and debugging straightforward.
Synchronization timeout and safe apply
Firewall synchronization operates within defined timeout limits. The process first reaches a ready state; then the test and apply steps are executed. A long-running or stuck operation is bounded by the system.
Parallel namespace sync
When many namespaces are present, firewall synchronization runs in batches in parallel. This makes it operationally manageable for each namespace to have its own rule set in multi-tenant environments.
Automatic rule types
Automatic rule types such as pool-tcp-udp, ftp-allow, l4-snat, l4-any-dnat, l4-any-snat, inline-dnat, fw-access-allow, fw-access-dnat, gtm-dns-dnat, gtm-access-dnat, local-deny and be-mark can be generated from ADC objects.
Connection tracking
Return flows for RELATED and ESTABLISHED traffic are recognized automatically. This reduces the need to write separate manual rules for every return packet in stateful services.
Hashlimit and connlimit
Per-source rate limits and connection limits are supported. Excessive connections, reset packets, ICMP packets, DNS/NTP UDP floods or new TCP connection attempts from the same IP can all be bounded.
ICMP and IPv6 neighbor discovery
Blocking ICMP entirely can impair core network functions such as IPv6 and Path MTU Discovery. TR7 handles ICMP policies with granularity; the necessary discovery and control messages can be managed safely.
Final rule set after error recovery
After faulty rules are commented out, the final rule set is written back to disk. Operators can see which line was disabled and correct it. The system produces a visible, actionable result rather than a silent failure.
When to use it
SSH brute-force reduction on the management interface
SSH connections to the management interface are bounded with a per-source limit. If the same IP exceeds the defined threshold it is temporarily quarantined. The brute-force surface is reduced while management access remains open.
Country-based access policy
Only traffic from selected countries is permitted; all others are dropped. This provides a fast control for country-based compliance and risk reduction in finance, public sector or healthcare systems.
Multi-tenant DNAT separation
While 1.2.3.4 → 10.0.0.5 DNAT is applied in Tenant A's namespace, Tenant B can use the same internal CIDR with a different rule. Namespace isolation ensures the two tenants' NAT policies do not conflict.
Built-in DDoS mitigation
UDP zero-byte flood, DNS/NTP flood, abnormal TCP, fragment and connection flood behaviors are mitigated with hashlimit, connlimit and quarantine mechanisms. Basic L3/L4 protection is applied without a separate scrubbing device.
Controlled transit between segments via FORWARD chain
When transit traffic is needed between two backend segments, controlled passage is established with FORWARD rules. Which source can reach which destination on which port is defined precisely.
Inline DNAT publishing
A backend IP is published through TR7 and incoming traffic is delivered to the relevant backend via inline DNAT. The TR7 security and routing layer is inserted without changing the application or backend IP plan.
Frequently asked questions
What is the difference between per-namespace firewall and a global firewall?
If a faulty rule is written, does the entire firewall break?
Are IPv6 rules managed separately from IPv4 rules?
Is a separate device required for DDoS protection?
Can firewall rules be generated automatically from ADC objects?
How does GeoIP matching work and does it affect performance?
Manage network security from the same console as your ADC
Namespace isolation, DDoS directives, DNAT/SNAT and automatic rule generation — let us walk through a live setup in your own environment.