The Access Gateway solution is implemented within a customer’s infrastructure, and can be deployed in the cloud, on-premises, or within a hybrid solution. It’s provided by Okta as an Open Virtual Appliance.
You can achieve high availability by using a load balancer. Okta recommends that the Access Gateway replication configuration for the load balancer use DNAT and session persistence using a hash of source IP address and source port or cookies. See Load balancers for information on how Access Gateway uses load balancers.
Additionally, the load balancer should perform health checks using ICMP or HTTPS with HTTP keepalives enabled for a duration that exceeds the health check interval.
Access Gatewayuses the term node to refer to instances of the gateway with the same configuration. These nodes typically serve as fallbacks for each other.
A group of Access Gateway instances within a given infrastructure is referred to as a cluster. In order for the Access Gateway instances to properly replicate their configuration, all instances within the cluster must be able to communicate with each other. Access Gateway cluster members communicate using SSH over port 22 and initially HTTPS over port 443.
Contact Okta Support if you require any additional details or information on load balancing and high availability techniques.
You can achieve disaster recovery (DR) by leveraging Global Server Load Balancing (GSLB) or modifying public and private IP address assignments.
Protected applications must be available as part of the disaster recovery solution and Access Gateway must have access to the protected disaster recovery applications.
All external (internet-based) end users must have access to both the primary production and disaster recovery solutions. Okta recommends that you leverage DNAT to increase Access Gateway's ability to provide accurate audit logs on the correct origins of the user.
Admin Console Considerations
The Access Gateway Admin UI console hostname should not be resolvable using public DNS. It should only be resolvable through internal DNS, such as split DNS.