All Products
Search

This Product

    Server Load Balancer:Build an Internet firewall using GWLB

    Document Center

    Server Load Balancer:Build an Internet firewall using GWLB

    Last Updated:Jun 20, 2026

    To address the management complexity and security risks caused by fragmented public access points and inconsistent security policies in cloud environments, you can build an Internet boundary firewall by integrating Gateway Load Balancer (GWLB) with an IPv4 gateway. This solution uses the IPv4 gateway to centrally control all public traffic entering or leaving the VPC and routes it through GWLB to network virtual appliances for deep inspection and filtering. This enables centralized enforcement of security policies, reduces security risks, and improves network management efficiency.

    Overview of the GWLB and IPv4 gateway integration solution

    In traditional public service deployments, resources inside a VPC communicate directly with the Internet by binding public IP addresses. This approach introduces several security issues:

    • Wide attack surface: Each bound public IP acts as a direct exposure point to the Internet. As the number of such IPs grows across different resources, the enterprise’s network security perimeter becomes fragmented, making unified traffic monitoring and policy enforcement difficult.

    • Complex policy management: Security policies (such as security groups) must be configured and maintained separately for each resource with a public IP. This increases operational overhead and time costs and raises the risk of misconfigurations that compromise security.

    • Lack of deep inspection: Security groups and network ACLs enforce access control primarily at Layer 4 (based on IP addresses and ports). They cannot perform deep packet inspection (DPI), intrusion prevention, or other Layer 7 security protections.

    By deploying the IPv4 gateway together with GWLB, you can build a centralized, transparent, and scalable Internet boundary firewall. The IPv4 gateway centrally manages all inbound and outbound public traffic from the VPC. This traffic is then routed via Gateway Load Balancer endpoints (GWLBe) to backend network virtual appliances (such as firewalls) for deep inspection. After inspection, the traffic is routed back through the corresponding GWLBe and finally forwarded to the application servers.

    Key features

    • IPv4 gateway

      • Centralized control of public traffic: By combining the IPv4 gateway with route tables and other components, you can ensure all public traffic passes through the IPv4 gateway. This simplifies unified security policy enforcement and auditing and effectively reduces security risks from decentralized access.

    • GWLB

      • Transparent traffic inspection: GWLB operates as a Layer 3 network gateway. Traffic retains its original source and destination IP addresses during inspection by network virtual appliances, requiring no changes to clients or backend services.

      • Scalable network virtual appliances: You can add or remove network virtual appliances behind GWLB at any time based on changes in service traffic.

      • Cross-zone high availability deployment: GWLB and its backend network virtual appliances can be deployed across multiple zones. If a network virtual appliance or GWLBe fails in one zone, traffic automatically shifts to healthy nodes in other zones, ensuring high availability of security services.

    Scenarios

    • Centralized security compliance auditing: Provides a unified cluster of security appliances for industries with strict compliance requirements (such as finance and government) to enable consistent auditing, monitoring, and event tracing of public traffic logs and security policies.

    • Deep security protection for public services: Delivers deep content inspection for websites, APIs, or applications exposed to the Internet, effectively defending against web attacks, malicious scans, virus intrusions, and other advanced threats.

    • Secure outbound access for VPC resources: Offers a secure egress channel for VPC resources that actively access the Internet (for tasks like patch updates or external API calls), preventing access to malicious sites and data leakage.

    Limits

    • At least one network virtual appliance must run behind GWLB.

    • The access policy (for example, security group rules) for GWLB backend servers must allow UDP traffic on port 6081 (the Geneve protocol port).

    • When creating an endpoint service, you must select a region and zone that support both PrivateLink and GWLB instances. For information about the regions and zones that support PrivateLink and GWLB instances, see Regions and zones that support PrivateLink and Regions and zones that support GWLB.

    • The zones where GWLBe is deployed must be a subset of the zones where the endpoint service resources (GWLB) are deployed to establish a connection.

    Scenario example

    A company’s core business system runs in a VPC in the China (Ulanqab) region of Alibaba Cloud. To ensure high availability, application server ECS instances are distributed across two zones (Ulanqab Zone B and Ulanqab Zone C) and serve external traffic by directly binding elastic IP addresses (EIPs). As the business scales, this deployment model—due to its fragmented public entry points—makes it hard to enforce unified security policies and auditing, failing to meet the company’s growing need for centralized security control. Additionally, this model lacks deep traffic inspection capabilities, making it ineffective against increasingly sophisticated cyberattacks.

    To resolve these issues, the company can deploy GWLB together with an IPv4 gateway to build a highly available Internet boundary firewall. This setup enables centralized traffic inspection and management, significantly reducing security risks and enforcing consistent security protection policies.

    Prerequisites

    • You have created a business VPC and a security VPC, configured business subnets and GWLB subnets in Zone B and Zone C of the business VPC, and set up security subnets in Zone B and Zone C of the security VPC. For more information, see Virtual Private Cloud and vSwitch.

    • You have created application server ECS instances in the business VPC and deployed application services on them. If an ECS instance needs public network communication, assign it a public IP address.

    • You have created and activated an IPv4 gateway for the business VPC.

    • You have created the required route tables, including the IPv4 gateway route table, business subnet route tables, and GWLBe subnet route tables.

    • You have created at least two ECS instances in the security VPC to simulate network virtual appliances.

      Important

      Ensure the ECS instance types in the security VPC support jumbo frames because Geneve encapsulation adds 68 bytes to the original packet, which may exceed 1500 bytes. For more information, see Network maximum transmission unit and Instance families that support jumbo frames.

    • You have created security groups for all ECS instances in both the business VPC and security VPC. Ensure the security group for ECS instances in the security VPC allows UDP traffic on port 6081 and permits the ports and protocols required for health checks.

    Reference example: CIDR block planning

    VPC

    Zone

    CIDR blocks and resources

    Business VPC

    Primary CIDR block: 192.168.0.0/16

    Zone B

    • GWLBe_01 subnet B: 192.168.101.0/24

    • Business subnet B: 192.168.1.0/24

    • Application server ECS_B_01 (bound to EIP): 192.168.1.153

      Reference example: Deploy a test service on ECS_B_01 (using Alibaba Cloud Linux 3)

      yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS_B_01." > index.html

    Zone C

    • GWLBe_02 subnet C: 192.168.102.0/24

    • Business subnet C: 192.168.2.0/24

    • Application server ECS_C_01 (bound to EIP): 192.168.2.151

      Reference example: Deploy a test service on ECS_C_01 (using Alibaba Cloud Linux 3)

      yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS_C_01." > index.html

    Security VPC

    CIDR block: 10.0.0.0/16

    Zone B

    • Security subnet B: 10.0.1.0/24

    • Network virtual appliance ECS_01: 10.0.1.40

    Zone C

    • Security subnet C: 10.0.2.0/24

    • Network virtual appliance ECS_02: 10.0.2.170

    Procedure

    Step 1: Configure Gateway Load Balancer

    Create a GWLB instance

    An instance is a load balancing service entity. Create a GWLB instance first.

    1. In the top menu bar of the Gateway Load Balancer (GWLB) console, select the region where you want to deploy the GWLB instance.

    2. On the Instances page, click Create GWLB.

    3. On the Gateway Load Balancer purchase page, configure the GWLB instance settings, then click Buy Now and follow the console prompts to complete instance activation.

      In this scenario, set Region and zone to China (Ulanqab), VPC to the security VPC you created, and Zone to Ulanqab Zone B and Ulanqab Zone C. Select the vSwitch IDs of the corresponding security subnets in each zone. Use default values or adjust as needed for other GWLB instance settings not listed here.

    4. Return to the Instances page and select the appropriate region to view your new instance.

    Create a backend server group

    Create a server group and add backend servers to receive client requests forwarded by GWLB.

    1. In the navigation pane on the left, choose GWLB > Server Group.

    2. On the Server Group page, click Create Server Group.

    3. In the Create Server Group dialog box, configure the server group parameters, then click Create.

      In this scenario, set Server Group Type to Server and VPC to the security VPC you created (the same VPC as the GWLB instance). Use default values or adjust as needed for other server group settings not listed here.

    4. In the The server group is created dialog box, click Add Backend Server.

    5. In the Add Backend Server panel, select the ECS_01 and ECS_02 instances you created, then click OK.

    Configure listeners

    Configure a listener for the instance and associate it with the backend server group to forward traffic on all ports to backend servers using the Geneve protocol.

    1. In the navigation pane on the left, choose GWLB and click the instance ID.

    2. Click the Listener tab, then click Create IP Listener.

    3. On the Create IP Listener configuration page, select Server Group Type, choose the server group you created, then click OK.

      Use default values or adjust as needed for other IP listener settings not listed here.

    Step 2: Configure network virtual appliances

    Because GWLB operates in transparent mode at Layer 3 of the OSI model, you must adapt the network virtual appliances deployed behind it to correctly receive, process, and return Geneve-encapsulated traffic.

    Alibaba Cloud GWLB supports integrating third-party network virtual appliances (such as Fortinet and Hillstone) into the backend server group. This topic uses iptables to simulate a backend network virtual appliance. Follow your device vendor’s instructions for actual configurations.

    Reference example: Configure iptables on ECS_01 (using Alibaba Cloud Linux 3)

    # Step1: Save the configuration script to a file
cat > setup_gwlb_multi_iptables.sh <<'EOF'
#!/bin/bash
# setup_gwlb_multi_iptables.sh
# For multi-zone GWLB deployments, automatically configures IP forwarding, iptables, and hairpin NAT rules
# ---- 1. Configuration parameters (modify as needed) ----
instance_ip="10.0.1.40" # Private IP of this ECS instance, e.g., ECS_01 in Ulanqab Zone B 
gwlb_ip1="10.0.1.41"   # Private IP of GWLB in Ulanqab Zone B
gwlb_ip2="10.0.2.171"  # Private IP of GWLB in Ulanqab Zone C
# ---- 2. Enable IPv4 forwarding ----
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/00-defaults.conf
sysctl -p /etc/sysctl.d/00-defaults.conf
# ---- 3. Install iptables service ----
yum install iptables-services -y
# ---- 4. Enable and start iptables service ----
systemctl enable iptables
systemctl start iptables
# ---- 5. Set basic iptables policies to accept all traffic (for testing/POC only; restrict as needed in production) ----
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
# ---- 6. Clear all iptables tables and rules ----
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
# ---- 7. Configure hairpin NAT rules for multi-zone GWLB ----
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip1 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip1:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip1 -d $gwlb_ip1 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p udp -s $gwlb_ip2 -d $instance_ip -i eth0 -j DNAT --to-destination $gwlb_ip2:6081
iptables -t nat -A POSTROUTING -p udp --dport 6081 -s $gwlb_ip2 -d $gwlb_ip2 -o eth0 -j MASQUERADE
# ---- 8. Save iptables rules ----
service iptables save
echo "【Done】ECS $instance_ip has applied NAT and forwarding rules for multi-zone GWLB!"
EOF
# Step2: Make the script executable
chmod +x setup_gwlb_multi_iptables.sh
# Step3: Run immediately
sudo ./setup_gwlb_multi_iptables.sh

    Step 3: Configure PrivateLink

    Configure an endpoint service

    Expose the GWLB instance as a service resource in an endpoint service for access by the business VPC.

    1. On the Endpoint Services page, click Create Endpoint Service.

    2. On the Create Endpoint Service page, configure the endpoint service settings, then click OK.

      In this scenario, set Region to China (Ulanqab), Service Resource Type to GWLB, Select Service Resource to Ulanqab Zone B and Ulanqab Zone C, choose the GWLB instance you created as the service resource, and set Automatically Accept Endpoint Connections to Yes. Use default values or adjust as needed for other endpoint service settings not listed here.

    Configure Gateway Load Balancer endpoints

    As a service consumer, create GWLBe instances to connect to the endpoint service.

    1. On the Endpoints page, click the GWLB Endpoint tab, then click Create Endpoint.

    2. On the Create Endpoint page, configure the GWLBe_01 settings, then click OK.

      Configuration for this scenario is as follows. Use default values or adjust as needed for other endpoint settings not listed here.

      Parameter

      Description

      Region

      This topic selects China (Ulanqab).

      Endpoint Name

      Enter a custom name for the endpoint.

      Endpoint Type

      Select the node type for the endpoint. This topic selects GWLB Endpoint.

      Type

      This topic selects Select Service and chooses the endpoint service you created.

      VPC

      Select the VPC for the endpoint. This topic selects the business VPC ID.

      Zones and vSwitches

      Select the zone corresponding to the endpoint service, then choose a vSwitch in that zone. The system automatically creates an endpoint elastic network interface (ENI) under this vSwitch.

      This topic selects Ulanqab Zone B and the vSwitch ID of the GWLBe subnet in Zone B.

    3. Repeat the creation steps to create GWLBe_02. Select Ulanqab Zone C and the vSwitch ID of the GWLBe subnet in Zone C.

      Note

      Ensure the endpoint connection status shows as Connected.

    Step 4: Configure routing

    Configure routes to direct traffic to GWLBe.

    1. In the top menu bar of the Route Table page, select the region of the route table.

      In this scenario, select China (Ulanqab).

    2. Follow the instructions below to click the ID of each target route table and configure routes on the route table details page.

      Note

      On the route table details page, under the Route Entry List > System Route tab, you can view system route entries.

      The system automatically adds the following system routes to custom route tables: routes with destination CIDR blocks matching the vSwitch CIDR blocks in the VPC, enabling communication between cloud resources within those vSwitches.

      • IPv4 gateway route table: The IPv4 gateway route table must contain entries that route traffic destined for application servers to GWLBe.

        On the route table details page, under the Route Entry List > System Route tab, find the target system route entries. In the Operations column, click Modify. In the Modify Route Entry dialog box, configure as follows, then click OK.

        After configuration, these route entries appear under the Custom Route tab.

        Configuration

        System route entry with destination CIDR block 192.168.1.0/24

        System route entry with destination CIDR block 192.168.2.0/24

        Next Hop Type

        Select GWLB Endpoint.

        GWLB Endpoint

        Select the existing GWLBe_01 in zone B.

        Select the existing GWLBe_02 in zone C.

      • Business subnet route tables: The business subnet route tables must contain entries that route all traffic from application servers to GWLBe.

        On the route table details pages for the business subnets in Ulanqab Zone B and Zone C, go to the Route Entry List > Custom Route tab and click Add Route Entry. In the Add Route Entry dialog box, configure as follows, then click OK.

        Setting

        Business subnet B route table

        Business subnet C route table

        Destination CIDR Block

        0.0.0.0/0

        Next Hop Type

        Select GWLB Endpoint.

        GWLB Endpoint

        Select GWLBe_01 in Zone B.

        Select the GWLBe_02 you created in Ulanqab Zone C.

      • GWLBe subnet route tables: The GWLBe subnet route tables must route inspected return traffic to its final destination. For Internet-originated traffic, local routes ensure delivery to application servers. For traffic from application servers, add a route that sends all traffic to the IPv4 gateway.

        On the route table details pages for the GWLBe subnets in Ulanqab Zone B and Zone C, go to the Route Entry List > Custom Route tab and click Add Route Entry. In the Add Route Entry dialog box, configure as follows, then click OK.

        Setting

        GWLBe subnet route table

        Destination CIDR Block

        0.0.0.0/0

        Next Hop Type

        Select IPv4 Gateway.

        IPv4 Gateway

        Select the IPv4 gateway you created.

    Routing configuration reference: Route entries for the IPv4 gateway route table, business subnet route tables, and GWLBe subnet route tables (showing only custom route entries)

    • IPv4 gateway route table configuration

      Destination CIDR Block

      Next hop

      Route entry type

      192.168.1.0/24

      Gateway Load Balancer endpoint (GWLBe_01)

      Custom route entry

      192.168.2.0/24

      Gateway Load Balancer endpoint (GWLBe_02)

      Custom route entry

    • Business subnet route table configuration

      Subnet type

      Destination CIDR Block

      Next hop

      Route entry type

      Business subnet B

      0.0.0.0/0

      Gateway Load Balancer endpoint (GWLBe_01)

      Custom route entry

      Business subnet C

      0.0.0.0/0

      Gateway Load Balancer endpoint (GWLBe_02)

      Custom route entry

    • GWLBe subnet route table configuration

      Subnet type

      Destination CIDR Block

      Next hop

      Route entry type

      GWLBe subnet B

      0.0.0.0/0

      IPv4 gateway

      Custom route entry

      GWLBe subnet C

      0.0.0.0/0

      IPv4 gateway

      Custom route entry

    Step 5: Verification tests

    Log on to a security appliance server and capture all packets on port 6081 by running the following command:

    tcpdump -i any port 6081

    The output shows request and response packets from application server ECS instances, confirming that GWLB successfully routes traffic to network virtual appliances for security inspection.

    Test inbound traffic connectivity

    1. From any client with Internet access, run curl http://<EIP bound to application server ECS_B_01> and curl http://<EIP bound to application server ECS_C_01> to verify normal application access.

      C:\Users\Administrator>curl http://8.xxx.56/
Hello World ! This is ECS_C_01.
C:\Users\Administrator>curl http://8.xxx.130/
Hello World ! This is ECS_B_01.

    2. On any backend ECS instance of GWLB, open a command line window and run tcpdump -i any port 6081 to capture all packets on port 6081.

      If the output shows Geneve-encapsulated traffic with inner packets like IP <client public IP>.xxxxx > <application ECS private IP>.http ..., GWLB is correctly distributing external traffic to security appliances for processing.

      10:24:36.525075 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.525098 IP iZ0jlgsxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [SEW], seq 2485172945, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:24:36.526547 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.526549 IP iZ0jlgxxx .56736 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [S,E], seq 3488689686, ack 2485172946, win 59220, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:24:36.572545 IP 10.0.1.41.56736 > iZ0jlgxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572551 IP iZ0jlgs4u5xxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [.], ack 1, win 255, length 0
10:24:36.572552 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.572554 IP iZ0xxx .56736 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [P.], seq 1:77, ack 1, win 255, length 76: HTTP: GET / HTTP/1.1
10:24:36.622282 IP 10.0.1.41.56736 > iZ0jlgsxxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.622288 IP iZ0jlgs4uxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 47.83.xxx.59927 > 192.168.1.153.http: Flags [F.], seq 77, ack 269, win 254, length 0
10:24:36.623401 IP 10.0.1.41.56736 > iZ0jlgs5xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0
10:24:36.623481 IP iZ0jlgs4uxxx .56736 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153.http > 47.83.xxx.59927: Flags [F.], seq 269, ack 78, win 463, length 0

    Test outbound traffic connectivity

    1. Log on to any application server and run ping www.aliyun.com to verify normal Internet access.

      [root@iZ0jl xxx xxx ~]# ping www.aliyun.com
PING www.aliyun.com.w.cdngslb.com (124.238.xxx.xxx) 56(84) bytes of data.
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=1 ttl=51 time=17.3 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=2 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=3 ttl=51 time=15.1 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=4 ttl=51 time=14.5 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=5 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=6 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=7 ttl=51 time=14.4 ms
64 bytes from 124.238.xxx.xxx (124.238.xxx.xxx): icmp_seq=8 ttl=51 time=14.4 ms

    2. On any backend ECS instance of GWLB, open a command line window and run tcpdump -i any port 6081 to capture all packets on port 6081.

      The output shows request and response packets from application server ECS instances, confirming that outbound traffic from application servers passes through GWLB backend network virtual appliances for inspection and pass-through.

      10:15:18.247012 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.247028 IP iZ0jlgs xxx > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 8, length 64
10:15:18.261183 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:18.261192 IP iZ0jlgs xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 8, length 64
10:15:19.248397 IP 10.0.1.41.32236 > iZ0jlgs xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo request, id 9, seq 9, length 64
10:15:19.248419 IP iZ0jlg xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 192.168.1.153 > 124.238.xxx          : ICMP echo reply, id 9, seq 9, length 64
10:15:19.262605 IP 10.0.1.41.32236 > iZ0jlg xxx.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo request, id 9, seq 9, length 64
10:15:19.262613 IP iZ0jlg xxx.32236 > 10.0.1.41.geneve: Geneve, Flags [none], vni 0x0, options [32 bytes]: IP 124.238.xxx    > 192.168.1.153: ICMP echo reply, id 9, seq 9, length 64

    References

    • GWLB billing overview: GWLB uses pay-as-you-go pricing. Costs include GWLB instance fees and LCU fees.

    • PrivateLink billing: GWLB requires GWLBe to deliver services. GWLBe is priced and billed independently by the PrivateLink service.

    • When deploying GWLB, enable the following features:

      • GWLB health check: Detects the availability of backend network virtual appliances. If a device fails, new requests are automatically routed to healthy backend devices.

      • Connection draining: Smoothly handles existing connections when removing a backend network virtual appliance.

      • Rebalance existing traffic: When a backend network virtual appliance fails or is removed, GWLB reroutes existing traffic to healthy backend devices to prevent service disruption.

    • For more information about PrivateLink and IPv4 gateway: