Example architectureThe Access Gateway solution is implemented within a customer’s infrastructure, and can be deployed in the cloud, on-premise, or within a hybrid solution. It’s provided by Okta as an Open Virtual Appliance.
High availability is achieved through the use of a load balancer. For information on how Access Gateway uses load balancers see About load balancers. Okta recommends that the Access Gateway replication configuration for the load balancer use DNAT and session persistence via a hash of source IP address and source port. Additionally, the load balancer should perform health checks via ICMP or HTTPS with HTTP keepalives enabled for a duration that exceeds the health check interval.
Access Gateway uses the term node to refer to instances of the gateway with the same configuration. Access Gateway 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.
See the Firewall and Access Requirements section in Prerequisites for Deploying Access Gateway for details about ports etc.
Please contact Okta Support if you require any additional details or information on load balancing and high availability techniques.
Disaster recovery (DR) can be achieved by leveraging Global Server Load Balancing (GSLB) or modifying public and private IP address assignments in the event of a disaster recovery scenario. Please note that protected applications must be available as part of the disaster recovery solution and that the 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. It is recommended that DNAT be leveraged to increase the ability of the Access Gateway to provide accurate audit logs on the correct origins of the user.
Admin Console Considerations
The admin console hostname should not be resolvable via public DNS; it should only be resolvable through internal DNS (such as split DNS).