Gateway Mode

Gateway Mode is the deployment in which the gateway of the Backend Services is TR7 (the default gateway of the server is an address on TR7; the SNAT field of the Backend Service is Use Client IP). TR7 connects to the server not with its own address but with the client's real IP address; the server's response returns to TR7 again through the gateway.

The server sees the client itself, not the load balancer: logs, access lists and IP-based rules work with the real address without any change in the application. Even in TCP applications where the client address cannot be carried in a header and Proxy Protocol is not supported, the source address is preserved end to end. 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 Gateway Mode field in the AGS module is a different concept: it determines the operating mode of a vService as an access gateway (Standalone Application, Portal, Portal Application). For details, see AGS - AAM › Flowchart.

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. Gateway 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

Gateway

Return path is TR7

The server's default gateway is TR7; the response to clients in other networks returns through TR7

HTTP and TCP

No header needed

On HTTP and L7 TCP vServices, the client address is carried in the connection itself

Single Change on the Server

Only the default gateway

On the server, only the default gateway is set to TR7; the application itself does not change

Controlled Egress

Server's outbound access

The server's access to other networks is opened by rules in the TR7 firewall

Cluster

Gateway moves to the other device

When the gateway address is defined as a VIP, the address moves to the other device on device failure

Gateway Mode

The diagram shows the flow of traffic: the VIP to which the client connects, TR7 and the Backend Service are on the same interface (1G-1 in the diagram) and in the same network; the client comes from another network (x.x.x.x in the diagram). The default gateway of the Backend Service is TR7's VIP address in this network (172.16.102.92).

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); whichever device is active, the Backend Service sees the client's address as the source of the connection. The Backend Service sends the response to the client's address; since this address is not in its own network, the packet reaches the gateway, that is, TR7. 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.102.90 and the other device uses 172.16.102.91. 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 four 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.102.161	8080
3	Backend Service → TR7	172.16.102.161	8080	x.x.x.x (Client IP), through the gateway 172.16.102.92	Source port of step 2
4	TR7 → Client	172.16.102.92 (VIP)	443	x.x.x.x (Client IP)	Source port of step 1

Color	Meaning
	Request
	Response

In step 2, the source of the packet is not TR7's address but the client's address; in step 3, the Backend Service sends the response to this address and the packet is delivered to TR7, which is the gateway. When the VIP moves to the other device, the gateway address moves with it; the addresses in the table do not change.

Why Gateway Mode?

Deployments with source address translation	With Gateway Mode
The server sees TR7's address as the source of the connection.	The server sees the real client IP address as the source of the connection.
The client address is carried in a header or with Proxy Protocol; the application needs to read it.	The address is carried in the connection itself; no additional setting is needed in the application, and on the server only the gateway is set to TR7.
In TCP applications that cannot carry a header, the client address reaches the server only if the application supports Proxy Protocol.	On HTTP and L7 TCP vServices, the source address is preserved whatever the application protocol is.
IP-based access lists and rate limits on the server see a single address, TR7.	IP-based rules on the server recognize each client separately.

How Does Traffic Flow?

ClientReaches the application at the vService address

RequestTo the vService addressResponseFrom the vService address

TR7Gateway of the serversTLSBot/DDoSLBWAFAGSWAF and AGS on HTTP vServices only

RequestWith the client's addressResponseTo the gateway, that is, TR7

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 returnsThe Backend Service sends the response to the client address; the packet reaches TR7, which is the gateway, and TR7 forwards the response to the client.

RequestResponse

TR7's capabilities are not given up while the client address is preserved: the connection still terminates on TR7, the request and the response pass through the same device, and the inspection and distribution features offered by the vService type remain in use.

Highlights

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

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

Application code does not changeThe only change on the server side is the default gateway. The application does not need to read headers or support Proxy Protocol; legacy and closed-source software runs as it is.

Return path provided by the gatewaySince the server's default gateway is TR7, the response packets to clients in other networks return to TR7; the connection passes through TR7 in both directions.

Server egress is also under controlThe server's update traffic or its traffic to other networks also passes through TR7; this transit is closed by default and is opened with FORWARD rules defined in the firewall.

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

Security layers in placeBot/DDoS on L7 TCP vServices and, in addition, WAF and AGS on HTTP vServices are enabled on the same vService.

High availability with clusterA VIP address is used as the gateway of the servers; when a device goes out of service, the gateway address moves to the other device.

When Is It Preferred?

Non-HTTP applications TCP services

In TCP applications where the client address cannot be carried in a header and Proxy Protocol is not supported, the server continues to see the real source of the connection.

Logging and audit requirements Real address

If the real client IP address must be present in server logs and application records, the address is recorded directly, without an additional field or header.

Applications that cannot be changed Compatibility

Applications that perform IP-based authorization or whose configuration cannot be changed work the same way when placed behind the load balancer.

Requirements of this deployment

• The client must be in another network: the server sends the response to the gateway only for addresses outside its own network. The response to clients in the same network as the server does not return to TR7.
• All of the server's off-network traffic passes through TR7: the connections initiated by the server itself and the responses to direct access to the server from other networks (management, monitoring, backup) also reach TR7. This forwarding is closed by default in TR7's firewall; rules for this traffic must be planned before rollout.

If the server's gateway cannot be changed

This deployment relies on the default gateway of the Backend Service being TR7. If changing the gateway on the server side is not wanted, the same result is achieved with Gateway Mode - Spoofing, without touching the server.

Related Pages

Gateway Mode - Spoofing

Preserving the client address without changing the server's gateway.

→

Backend Services

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

→

Firewall

Forwarding (FORWARD) rules for the server's access to other networks.

→

Interfaces

Interface IP and VIP addresses to be used as the gateway.

→