Deploying an ADC should not require changing backend IP addresses, gateways or network segments.
In traditional ADC deployment projects the largest cost is usually not the product itself — it is reshaping the existing network to fit the product. Changing backend default gateways, redesigning IP plans, reworking route behaviour or opening maintenance windows all carry significant risk in production environments.
In environments with hundreds or thousands of backends, the "change every server's gateway" approach is not viable. Some backends may have no gateway defined at all, others may rely on static routes, and others still may run on legacy systems that are difficult or impossible to modify. In these cases, inserting an ADC becomes a full network redesign project.
Forced network-segment merging is another problem. The VIP must sit in the DMZ, the backend must stay on the internal network, tenant networks must remain isolated, and the management plane must be kept separate. If the ADC cannot carry traffic across these domains in a controlled way, security segmentation breaks down or application teams are forced into unnecessary IP migration work.
A single reverse proxy model also fails to cover every need. Some applications require backends to see the real client IP; some L4 services need return traffic to bypass the ADC entirely; some inline scenarios require inserting the ADC without changing IPs or touching gateways. A single NAT-based model cannot address this range of requirements.
TR7 Deployment Topology Modes provide this flexibility: they let you choose the right traffic placement for each service without touching backend IP addresses, gateways or Route Table assignments.
Our approach
TR7 turns the deployment topology into an architectural decision that can be tailored to service type, network placement and migration risk.
L7 reverse proxy and transparent bind are supported side by side
In the classic reverse proxy model the client connects to TR7 and TR7 connects to the backend. In a transparent bind scenario, traffic flow is preserved so that the backend sees the real client IP as the source address.
L4 NAT, SNAT and DR modes offer distinct return paths
In NAT mode both destination and source translation are managed together. In SNAT mode only the source side is adjusted. In DR mode, return traffic goes directly to the client, providing a more efficient path for high-volume L4 workloads.
Cross-Route-Table forwarding connects segments without merging them
The Route Table hosting the VIP and the Route Table hosting the backend can be different. TR7 carries traffic across the two network domains in a controlled way, connecting DMZ, internal, tenant and management segments without flattening them.
IP-takeover inline inserts the ADC without modifying existing services
TR7 can take ownership of traffic destined for specific backend IPs and operate inline. The backend's IP address, gateway and application configuration remain unchanged while the ADC is inserted into the path.
Capabilities
Deployment Topology Modes cover network placements ranging from rapid single-interface setup to high-throughput L4 forwarding.
One-arm route-mode enables rapid deployment on a single interface
In one-arm mode, client and backend traffic can be handled on the same network side. TR7 receives service traffic through a single interface and forwards it to the relevant backend using routing rules. This model is suited to fast ADC deployment with minimal network changes. It is a practical starting point for pilot deployments, temporary transitions or low-risk rollout scenarios.
Two-arm gateway-mode enforces DMZ and internal network separation
In two-arm mode, TR7 is positioned between two distinct network segments. One side faces the client or DMZ network; the other faces the backend network. This makes the ADC not just a traffic forwarder but a policy-enforcing transit point at the network boundary. It is suited to enterprise architectures that require security and segmentation.
Reverse proxy mode delivers classic L7 vService behaviour
In reverse proxy mode the client connects to the VIP or vService on TR7, and TR7 opens a separate connection to the backend. TLS termination, WAAP, header manipulation, cookie security, content-aware rules and AAM integration are all fully applicable in this mode. This is the most common application delivery topology for HTTP and API traffic. Backends are never exposed directly to the internet or external networks.
Transparent L7 bind preserves the real client IP on the backend
In a transparent L7 scenario, the source IP seen by the backend is the real client address rather than the ADC address. This mode is valuable for applications that cannot rely solely on header-based client IP forwarding. Logs, access control and in-application IP-based decisions work more naturally. The network return path must be planned accordingly.
L2 Bridge mode reduces Layer 3 changes
Bridge mode allows TR7 to sit in the traffic path as a Layer 2 bridge. In this scenario the need for additional IP renumbering or broad routing changes is reduced. Existing addressing can be preserved when entering the traffic path across VMs, containers or segments. Bridge mode is useful in environments where network changes must be kept to a minimum.
Transparent gateway provides NAT-free inline transit
In transparent gateway mode TR7 is positioned at the transit point of the backend network. Source IP is preserved and NAT is not required. This mode is valuable in scenarios where backends must see the client IP naturally. Default route changes must be planned carefully and the return path must be explicitly controlled.
IP-takeover inline inserts the ADC without changing gateways
TR7 can take traffic ownership for designated backend IPs and operate inline. This mode is particularly valuable when a backend's IP address, default gateway or route settings cannot be changed. Even when the backend has no gateway configured, TR7 can position itself as the control point in the relevant traffic path. In large environments, controlled inline insertion replaces the need to modify hundreds of backends individually.
Cross-Route-Table forwarding connects services without merging networks
TR7 can listen on a VIP in one Route Table and forward traffic to a backend in a different Route Table. This allows DMZ, internal, tenant, management and distinct service zones to be connected to each other in a controlled way without being moved to the same network plane. Operators do not need to renumber backends or flatten networks. TR7 becomes a controlled transit point between Route Tables where security policy can be applied.
L4 NAT and SNAT modes are selected based on the required return path
In L4 NAT mode, destination and source translation are used together to guarantee the return path through TR7. In SNAT mode only the source side is adjusted, and the backend's existing return path design is respected. These two modes allow L4 traffic to be carried in a way that fits the network topology. Separate behaviour can be selected for UDP, TCP or specific port ranges.
L4 DR mode carries high-volume return traffic directly
In DR mode, request traffic is forwarded to the backend through TR7 while response traffic returns directly to the client. This model is advantageous for high-volume streaming, gaming, DNS or latency-sensitive L4 services. Because the ADC does not carry return traffic, the data path becomes more efficient. Backend and network return behaviour must be prepared correctly for DR scenarios.
L4 persistence and SIP persistence maintain session continuity
L4 persistence helps ensure that traffic from a specific client stays on the same backend target. CONNMARK, recent records and a configurable persistence window maintain flow continuity. SIP persistence provides specialised behaviour for session-sensitive protocols such as SIP traffic. This gives L4-level session consistency in addition to basic load distribution.
Automatic security rule generation simplifies service access
The required ingress permissions for L4 and vService definitions can be generated automatically. Appropriate accept rules are created for each front-end IP, port and protocol, reducing manual firewall errors. Automatic rule generation is especially important in inline and L4 scenarios. The operator selects the topology; TR7 consistently generates the basic permissions for the relevant traffic path.
Operational depth
Topology modes are operated together with L4 defaults, inline process behaviour, TR7 Route Tables, cluster role and error visibility.
L4 default behaviour
Round-robin algorithm, NAT mode and UDP protocol are available as the default starting values for a new L4 pool. Operators can change these to TCP, UDP, any protocol, port range or a different L4 algorithm based on service requirements. Defaults are intended for fast start-up; production behaviour should be reviewed explicitly.
L4 algorithm selection
Algorithms such as round-robin and weighted round-robin can be used for L4 distribution. The weighted model provides more balanced traffic distribution across backends with different capacities. Algorithm selection should be planned together with service type, capacity and session behaviour.
Inline takeover process
IP-takeover inline mode operates based on the relevant interface, backend IP and gateway information. If a gateway is not explicitly specified, the appropriate path can be derived from the existing network information. If the process stops unexpectedly, automatic restart can be applied.
Inline error reasons
In inline mode, conditions such as noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice and inactiveClusterIp can be surfaced as explicit error reasons. This tells the operations team precisely why something is not working rather than simply that it is not working. Error visibility is critical for operating inline topologies safely.
Cluster-aware inline behaviour
In a cluster environment, the inline takeover process should run only on the device that holds the active role. When the active device changes, inline traffic ownership moves to the relevant node. This model helps prevent two nodes from simultaneously claiming ownership of the same IP.
Default gateway independence
Inline transparent mode reduces dependency on the backend's default gateway setting. If the backend has no gateway or the gateway cannot be changed, TR7 can take over the relevant traffic path using the IP-takeover method. This capability enables controlled ADC deployment without opening maintenance windows or modifying backends.
Cross-Route-Table forwarding
The TR7 Route Table on which the VIP listens and the TR7 Route Table where the backend resides can be different. TR7 carries traffic between these two network domains, reducing the need for topology changes. This behaviour is particularly valuable for controlled transition from DMZ to internal network, from tenant network to shared service network, or between old and new network domains during migration.
When to use it
Inline deployment without touching backends
In large organisations, changing the IP, route or gateway of hundreds of backends is high risk. IP-takeover inline mode lets TR7 ADC be inserted into the traffic path while existing addressing is preserved.
Inserting the ADC for services that have no gateway
Some legacy or isolated backends may have no default gateway configured. In inline transparent mode TR7 can take over the relevant traffic without touching the backend's gateway setting.
Controlled service transit between distinct Route Tables
Organisations can listen for VIPs on a DMZ Route Table while keeping backends on an internal Route Table. TR7 provides controlled traffic transit between the two domains without merging networks or renumbering service IPs.
High-volume L4 gaming and streaming traffic
Gaming or streaming teams can use DR mode to send response traffic directly to the client. While TR7 makes the forwarding decision, load on the return data path is reduced and high-throughput scenarios become more efficient.
Frequently asked questions
Which deployment topology modes does TR7 support?
How does IP-takeover inline mode work?
What is the difference between L4 NAT, SNAT and DR modes?
What does cross-Route-Table forwarding provide?
Which error reasons can be monitored in inline mode?
When should one-arm be preferred over two-arm mode?
Fit TR7 to your existing network — without touching your backends
From one-arm to transparent inline, L4 DR to cross-Route-Table forwarding — let's walk through the right topology in a live setup.