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.
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.
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.
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.
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.
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.
The Built-In Firewall combines classic L3/L4 control with ADC-native automatic rule generation, DDoS mitigation, quarantine and namespace 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.
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.
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.
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 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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Namespace isolation, DDoS directives, DNAT/SNAT and automatic rule generation — let us walk through a live setup in your own environment.