Route Mode

Route Mode is the deployment in which the client IP address is preserved without source address translation and the return path is provided on the network side (the SNAT field of the Backend Service is Use Client IP; the server's gateway stays as it is, and the return traffic of the published services is brought to TR7 by a routing rule on the firewall or router). TR7 connects to the server with the client's real IP address; the response again passes through TR7 by the network's own routing decision.

The servers' settings are not touched: TR7 has an arm and an address in the server network, and the servers continue to use their own gateways. In this deployment, the main work is done not on TR7 but on the firewall or router in the network; the return path is defined there with a rule covering the published services and covers dozens of servers at once. This is the natural deployment for enterprise networks that manage traffic paths centrally. Because both the request and the response pass through TR7, this deployment is also known in the industry as an inline or transparent deployment.

This page describes a network deployment

The LB Mode field in the Network vService form also has an option named Route Mode; that option is a distribution method for L4 traffic and is different from the deployment described on this page. For details, see Network vService.

HTTP or TCP?

On HTTP vServices, the X-Forwarded-For header should be used first to pass the client address to the Backend Service, and on HTTP and L7 TCP vServices, Proxy Protocol should be used where the Backend Service supports it; these two methods pass the client address to the server without touching the network design. Route Mode is mostly preferred on L7 TCP vServices, that is, where the client address cannot be carried in a header and the application does not support Proxy Protocol.

Real IP

Source address preserved

The server sees the client's own IP address as the source of the connection

No SNAT

Address not translated

TR7 connects to the server not with its own address but with the client's address

Central Rule

Return path in the network

The return traffic of the published services is brought to TR7 by a routing rule in the network

Server Settings Unchanged

Gateway stays the same

The servers' gateway, address and routing settings are not changed

In the Server Network

TR7's second arm

TR7 connects to the server network with an arm; the routing rule targets the TR7 address in this network

Cluster

Rule targets a VIP

The routing rule targets a VIP address; the address moves to the other device on device failure

Route Mode

The diagram shows the flow of traffic in five steps: the VIP to which the client connects is on the interface in the publishing network (1G-1 in the diagram, VLAN_102), while the second interface through which TR7 reaches the Backend Service is in the server network (1G-2 in the diagram, VLAN_101). The default gateway of the Backend Service has not changed: it is not TR7 but the server network's own gateway (Internal Firewall in the diagram, 172.16.101.1).

In the diagram's example, TR7 connects to the Backend Service not with its own address but with the client's address (x.x.x.x). The Backend Service delivers the response to its own gateway to be sent to the client's address; the routing rule on the Internal Firewall (source 172.16.101.47:80, next hop 172.16.101.50) forwards the packet, without touching its addresses, to TR7's VIP address in the server network as the next hop instead of sending it to the client. The rule covers only the address and port of the Backend Service; the server's other traffic stays on its own path.

The health check is performed not with the client address but with the TR7 address in the Backend Service's route table: in the diagram's example, the active device uses 172.16.101.48 and the other device uses 172.16.101.49. This applies while the Health Check Source IP field of the Backend Service is at its default value; when another address is selected in the field, the check is performed from that address.

In the diagram's example, the source and destination details of the packets in the five steps of the connection are as follows:

Step	Direction	Source IP	Source Port	Destination IP	Destination Port
1	Client → TR7	x.x.x.x (Client IP)	Random	172.16.102.92 (VIP)	443
2	TR7 → Backend Service	x.x.x.x (Client IP)	Random	172.16.101.47	80
3	Backend Service → Internal Firewall	172.16.101.47	80	x.x.x.x (Client IP); the packet is delivered to the server's gateway (172.16.101.1)	Source port of step 2
4	Internal Firewall → TR7	172.16.101.47	80	x.x.x.x (Client IP); the packet's addresses do not change, the routing rule forwards the packet to the address 172.16.101.50 (TR7 VIP) as the next hop	Source port of step 2
5	TR7 → Client	172.16.102.92 (VIP)	443	x.x.x.x (Client IP)	Source port of step 1

Color	Meaning
	Request
	Response

In steps 3 and 4, the packet is the same and its addresses do not change; only its path changes. The packet addresses are the same as in Gateway Mode; the difference is that the response is brought to TR7 not by the server's gateway setting but by the routing rule in the network.

Why Route Mode?

Gateway Mode and Gateway Mode - Spoofing	With Route Mode
The return path is provided through the server's gateway; either the gateway is TR7 or TR7 picks up the return traffic in the same network.	The return path is provided at the network's routing point, with a routing rule.
The server's gateway traffic other than the published service also passes through TR7.	Only the service responses covered by the rule are routed to TR7; the server's other traffic stays on its own path.
The method is applied separately for each Backend Service or each server.	The rule is written at the network's routing point and covers the services published in that network together.
The decision is made at the level of the server or the server's network.	The decision is made at the central point managed by the network team and is monitored there.
The same setup is built again for each new server network.	A new server network is brought into scope by adding a rule to the routing point.

How Does Traffic Flow?

ClientReaches the application at the vService address

RequestTo the vService addressResponseFrom the vService address

TR7Forwards without translating the addressTLSBot/DDoSLBWAFAGSWAF and AGS on HTTP vServices only

RequestWith the client's addressResponseTo TR7 by the routing rule

Backend ServiceSees the client as the source

1. Request arrivesThe client connects to the vService address at which the application is published.
2. TR7 inspectsTLS termination, Bot/DDoS and rules are applied at the same point; on HTTP vServices, WAF and AGS are also at this point.
3. Forwards on behalf of the clientTR7 connects to the selected Backend Service using the client's IP address as the source address.
4. Response is routedThe Backend Service sends the response to its own gateway; the routing rule in the network brings the response to TR7 and TR7 forwards it to the client.

RequestResponse

The routing rule is the key to this deployment: it ensures that the response returns along the path it came from and that both directions of the connection pass through TR7. Without the rule, the response tries to go to the client without passing through TR7; TR7 cannot receive the response to the connection it opened and the connection cannot be established.

Highlights

Real client address end to endThe client's own IP address appears in the Backend Service's logs, access controls and rate limits.

Return path at a single pointThe response traffic of the published services is directed to TR7 by a routing rule defined on the firewall or router.

No setting change on the serverThe servers' gateway and routing settings stay the same; the change is made only at the network's routing point.

Part of the network policyThe return path to the load balancer is defined, documented and monitored in the same place as the other routing rules in the network.

TR7 side ready automaticallyWhen Use Client IP is selected, a Backend mark rule is generated automatically in the TR7 firewall, in the Backend Service's route table; packets returning from the Backend Service's address and port that belong to a connection opened by TR7 are matched with this connection.

Not dependent on headersX-Forwarded-For works only in HTTP; this deployment preserves the client address at the connection level and also applies to L7 TCP vServices.

Selected per serviceThe source address behavior is determined per Backend Service; on the same TR7, one service runs with Route Mode and another with source address translation.

High availability with clusterThe target of the routing rule is a VIP address; when a device goes out of service, the address moves to the other device and the rule in the network does not need to be changed.

When Is It Preferred?

Servers whose gateway is a firewall Routed network

If the servers' gateway is a firewall or router and changing this setting is not wanted, the return path is directed to TR7 at that point and the client address is preserved.

Environments where the server cannot be modified Hands-off

If the servers' gateway cannot be changed, the return path is solved on the network side, independently of the servers.

Centrally managed routing Central rule

In architectures where traffic paths are managed from a single point by the network team, the load balancer also becomes part of the same routing policy.

The main work is on the firewall side

On TR7, Use Client IP is selected on the Backend Service and TR7 has an address in the server network (a VIP in a cluster setup). No setting changes on the server or in the application. The operation of the deployment depends on three behaviors of the firewall or router in the network:

• Routing rule. Return traffic whose source is the address and service port of the Backend Service is routed to TR7. The rule must be written to cover only the published services: if connections initiated by the servers themselves and access that does not come through TR7 are routed to TR7, they are not forwarded by default in TR7's firewall. The target of the rule is TR7's address in the same route table as the Backend Service; in a cluster setup, this address is a VIP.
• Source address check. Packets going from TR7 to the server carry the client's address as the source. If source address validation (reverse path filtering, anti-spoofing) is enabled on the firewall, an exception must be defined for this traffic.
• Symmetric path. Both directions of the connection pass through TR7, and the response reaches TR7 through the arm that TR7 used when going to the server. If the response returns without passing through TR7, TR7 cannot receive the response to the connection it opened and the connection cannot be established.

If no change is wanted on the network side either, the same result is achieved with Gateway Mode - Spoofing.

Related Pages

Gateway Mode

The deployment in which the return path is provided by setting the server's gateway to TR7.

→

Backend Services

Source address selection: the SNAT field and the Use Client IP option.

→

Route Tables

Separate network space, default gateway and routes for each arm.

→

Network vService

LB Mode options for L4 traffic: Direct Server Return, Route Mode and SNAT.

→