GWLB instances - states, IP version, MTU, connection timeout - Server Load Balancer

Instance state

GWLB instances can be in the following states:

Instance state	Description	Lock type	Deletion allowed	Configuration update allowed
Running	Normal operation.	Not applicable	Yes	Yes
Creating	Creation in progress.	Not applicable	No	No
Updating configuration	Configuration update in progress.	Not applicable	No
Stopped	Instance stopped.	Overdue payment lock: Locked due to overdue payment. Complete the payment to unlock.	No

IP version

GWLB instances accept IPv4 traffic.

The GWLB instance uses private IPv4 addresses from its subnet to communicate with backend servers.

Cross-zone forwarding

Cross-zone forwarding is enabled by default and cannot be disabled at the moment. A GWLB instance distributes traffic to backend servers across all enabled availability zones in the region.

Maximum transmission unit

The maximum transmission unit (MTU) is the largest packet size transmittable over a network. It includes the IP header and payload, but not the Ethernet header.

GWLB MTU limit:

Maximum packet size: 1,500 bytes. Larger packets are dropped.
MTU settings for network virtual appliances:

GWLB encapsulates IP traffic with a Geneve header (+68 bytes) before forwarding to NVAs. To handle encapsulated 1,500-byte packets, ensure:
- Jumbo frames are enabled for the ECS instance where the NVA is deployed.
- The MTU of the NVA interface is set to at least 1,568 bytes.
  
  Configure this MTU within the NVA image per your appliance vendor documentation.
IP fragmentation:

GWLB does not support IP fragmentation.
Path MTU discovery (PMTUD):

GWLB does not generate the ICMP messages required to indicate that fragmentation is needed, and therefore does not support PMTUD.

Connection idle timeout

The connection idle timeout defines how long a connection can remain idle before GWLB closes it. Timeout behavior depends on the flow scheduling algorithm and traffic type.

TCP traffic handling

When the flow scheduling algorithm is five-tuple hash:

GWLB tracks TCP connection state. If no data transfers within the timeout period, the connection closes and existing traffic is dropped. The GWLB instance routes subsequent traffic to a new backend server. A new connection is established with the next request.

The default timeout is 350 seconds. You can customize the TCP connection idle timeout in listener settings. Valid range: 60 to 6,000 seconds.
Adjust the TCP connection idle timeout to optimize resource usage:
- Increase the timeout for long-lived connections (financial transactions, database interactions, ERP systems). Match or exceed backend NVA timeouts to prevent premature termination. For example, if your firewall timeout is 3,600 seconds, set GWLB to 3,700 seconds.
- Decrease the timeout for short-lived or bursty traffic to release idle connections and reduce resource consumption.
Note
If a TCP connection actively closes before the timeout, GWLB immediately deletes its state.
When the flow scheduling algorithm is two-tuple/three-tuple hash:

GWLB hashes flows by two-tuple (source IP, destination IP) or three-tuple (source IP, destination IP, protocol) to maintain server affinity. If a flow idles beyond the timeout, its state clears and subsequent packets may route to a different backend server.

The connection idle timeout is fixed at 350 seconds and cannot be changed.

Non-TCP traffic handling

Although UDP is connectionless, GWLB maintains flow state based on the scheduling algorithm to ensure server affinity. If a flow idles beyond the timeout, its state clears and subsequent packets may route to a different backend server.

The connection idle timeout for non-TCP traffic is fixed at 120 seconds and cannot be changed.

Traffic mode

By default, GWLB operates in load balancing mode, forwarding traffic from GWLB endpoints to backend servers.

For emergency response, troubleshooting, or NVA maintenance, switch to bypass mode. In bypass mode, GWLB returns traffic directly to the endpoint without forwarding to backend servers, ensuring uninterrupted service.

Note

Not enabled by default. Contact your account manager to use this feature.

Details of bypass mode

Traffic mode	Load balancing mode	Bypass mode
GWLB behavior	GWLB forwards traffic from the endpoint to backend servers for processing.	GWLB returns traffic directly to the endpoint without forwarding to backend servers.
Architecture diagram
Use cases	Default mode. Third-party firewalls process business traffic as expected.	Used for network and firewall maintenance: Emergency response: If traffic exceeds firewall cluster capacity, switch to bypass mode to prevent interruption. Switch back after scaling out the cluster. Troubleshooting: Analyze network issues without firewall interference. Device maintenance: Perform firewall upgrades (such as image updates) without interrupting network traffic.
Notes	-	Billing: In bypass mode, GWLB still forwards traffic, and you are still charged for LCUs based on traffic. Health check: In bypass mode, GWLB health checks run as expected.

Console

In the GWLB console, go to the Instance Details page. To the right of Traffic Processing Mode, click Modify to switch the traffic processing mode.

API

Switch the traffic mode by calling UpdateLoadBalancerAttribute and setting the TrafficMode parameter.

The following values are supported for the TrafficMode parameter:

LoadBalance (default): load balancing mode
ByPass: bypass mode

Query the traffic mode of a GWLB instance with:

Warning

Switching to bypass mode bypasses NVA security processing. Assess the associated security risks.
When switching to load balancing mode with stateful protocols, configure NVAs (such as firewalls) to handle mid-session traffic. Otherwise, existing connections may drop.

For example, with the TCP protocol, the firewall must allow a TCP session to be established without an initial SYN packet.
- How it works:
  - TCP three-way handshake: A TCP connection is established with a three-way handshake: the client sends a SYN packet, the server responds with a SYN-ACK, and the client confirms with an ACK.
  - After switching from bypass to load balancing mode, traffic routes through NVAs again. NVAs that require the initial SYN packet cannot recognize mid-stream packets from existing connections, causing those connections to drop. New connections are unaffected. Configure your NVA to accept TCP sessions without a SYN packet to prevent drops.
- Configuration example: For a FortiGate firewall, you can enable tcp-session-without-syn in the firewall policy. For more information, see the official documentation from your firewall vendor.

Server Load Balancer:GWLB instances