Current document describes steps to setup CGW in High Availability (HA) mode. User must understand concepts of Secure Private Access (SPA) first before navigating to below document.
Please refer below user guide to get more details on Secure Private Access (CGW) and CGW.
How it works?
CGW will be deployed in customer datacenters to provide Secure Private Access (SPA). Remote users will access private resources securely via CGW (Outside-In scenario).
CGWs are also deployed in customer datacenters/offices to provide Secure Internet Access (SIA) without having client on user’s devices. Users inside datacenters or offices who are sitting behind CGW will access internet via CGW (Inside-Out scenario).
Service continuity can be achieved by configuring or deploying CGW with high availability. It will require 2 physical nodes or 2 VMs running on 2 different servers/hardware.
CGW high availability model is based on Active Standby service connection. All the traffic will be handled by Active node and once Active node goes down, Standby node will take Active role and connect the service. Traffic will start flowing from current Active node.
Active node will have a floating IP configured on LAN interface which will act like Gateway IP for the devices behind CGW
Few important points for CGW HA deployment are listed below:
- Make sure another CGW VM or Standby node is deployed on different server/hardware in data center
- Make sure both CGW VMs are on same subnet
- LAN interfaces on CGWs must be accessible from each other
- IPs on both CGW LAN interfaces must be from same subnet (If CGW setup has 2 separate interfaces for WAN and LAN connectivity)
Please refer Deployment User Guide and deploy CGWs.
Refer SPA User Guide to create CGW and Trust Paths on admin console or workspace (Skip if already created).
3. Reference Architecture
Below example will describe basic CGW deployment with HA (High Availability) configuration.
- Both CGWs are deployed in Datacenter-1
- Both CGWs are deployed with 2 interfaces on each for separate WAN and LAN connectivity
- LAN interface subnet – 192.168.26.0/24
- LAN Interface next hop on both CGWs – 192.168.26.8/24
- Trust paths examples: 192.168.26.0/24 and 192.168.56.0/24
3. High Availability Configuration
3.1 Primary CGW Deployment
It is possible, if CGW is already deployed and customer wants to use same setup and configure another CGW as standby.
Once CGW is deployed and service is already in connected mode, follow below steps to configure existing or fresh CGW as Active / Master node.
- Execute below command to check if CGW is in connected or disconnected state
|sudo xlgateway status|
If not in connected state, then execute below command to connect service.
|sudo xlgateway connect|
While setting up first time, keepalived will be installed in background. Configuration step will ask to select the node type. Make CGW-1 (existing one or first CGW) as master. It will automatically identify LAN interface (which was attached during setup) as HA health monitoring interface. User must provide virtual IP to be installed on LAN interface, it will be used as floating IP. Make sure provided virtual IP belongs to same subnet as LAN interface IP. In above reference architecture example, 192.168.26.100/24 was used.
Verify CGW service and node status by using below command:
|sudo xlgateway status|
3.2 Secondary CGW Deployment
Use below commands to install standby CGW manually.
Note: Replace <workspace_name> and <cgw_name> with actual values before command execution.
|sudo apt update; sudo apt install curl -y; curl -s https://clientreleases.s3.us-west-1.amazonaws.com/cgw/xcgw_install.sh | bash /dev/stdin <workspace_name>,<cgw_name>,secondary|
During setup, select ‘n’ when prompted to login. Before login, we will need to configure the node as “Secondary” or “Primary”.
|sudo xlgateway setup|
Configure HA mode:
While setting up first time, keepalived will be installed in background. Configuration step to select the node type. Make CGW-2 (Standby node) BACKUP. It will automatically identify LAN interface (which was attached during setup) as HA health monitoring interface. User must provide SAME virtual IP to be installed on LAN interface which was configured on MASTER node.
Login to CGW using same credentials (workspace and CGW name). It can be fetched from admin console or the “sudo xlgateway status” output from CGW master node.
|sudo xlgateway login|
After successful login and verification, it will not connect the service on backup mode. Warning will be prompted on console.
Verify HA configuration using below command:
|sudo xlgateway status|
NOTE: If user executes “sudo xlgateway disconnect” , then it will be treated as an admin operation. It will restrict recovery utility to reattempt in case any abnormal behavior happens. Our recommendation is to not disconnect CGW manually after setting up HA.
How to verify CGW HA configuration is working as expected?
- Reboot of Master node:
- CGW-1 is Master node and in connected state (verify using “sudo xlgateway status”)
- Virtual IP on Master node is installed on LAN interface (verify using “ip addr”)
- On a client test machine, start ping to VM behind CGW to verify SPA works after CGW failover
- CGW-2 is Backup node and in disconnected state (verify using “sudo xlgateway status”)
- Virtual IP on Backup node is NOT installed on LAN interface (verify using “ip addr”)
- Execute “sudo reboot” on CGW-1. Ping on Client machine to VM behind CGW will be interrupted for few seconds.
- Check CGW-2 status after 10-15 seconds, It must become Master node and virtual IP will be installed on LAN interface.
- Verify ping on client machine and confirm SPA works.
- Check CGW-1 again, which will come up as backup node
- Shutdown of current Master node
- Execute same steps (instead of reboot, shutdown master node manually and confirm backup becomes master to serve the data traffic)
4. Disable / Remove High Availability Configuration
|sudo xlgateway unset-ha|
- If performed on Master node, then keepalived service will be stopped, HA config will be removed completely.
- If performed on Backup node, then keepalived service will be stopped, HA config will be removed completely, and application will logout.