Access Gateway deployment prerequisites

This topic describes the prerequisites for deploying Access Gateway.

Okta Access Gateway runs in on-premises or customer infrastructure as a service (IaaS) environments.

See Supported technologies for more information.

Access Gateway doesn't support SSL decryption.

Hardware requirements

The hardware that hosts the Access Gateway virtual appliance must meet certain instruction set requirements.

Access Gateway uses the SSE4.2 extensions to the x64 instruction set, which became available with the release of the Intel® Nehalem and AMD Bulldozer microarchitectures. The server that runs the Access Gateway virtual appliance must support this instruction set.

Account requirements for Okta orgs

The Access Gateway configuration process requires a super admin account to configure your Okta org as the Identity Provider. See Configure an Identity Provider in Access Gateway.

Firewall and access requirements

Ports and protocols

Access Gateway requires that various ports and protocols be open for use. This allows Access Gateway to accept incoming requests, proxy those requests to applications, provide administrative interfaces, and communicate with Okta and log server products.

Description Direction Protocol Port Comments
Okta org API access Outbound TCP/HTTPS 443 Your Okta org IP addresses may change. See Allow access to Okta IP addresses if you require specific IP address ranges to use as part of your firewall ACL.
Access Gateway updates Outbound TCP/HTTPS 443 If you require finer controls to access yum.oag.okta.com, you can configure access by IP address.

You can discover IP addresses using a tool such as NSLookup.

Okta reserves the right to change the IP addresses associated with Access Gateway updates, virtual private network (VPN) and similar services at any time. Confirm specific IP addresses with Okta Support.

Integrated applications Outbound TCP/HTTPS application ports Access Gateway communication to the protected application.
Access Gateway Admin UI console and apps Inbound TCP/HTTPS 443 All end users must be able to access Access Gateway directly using port 443 if it's acting as an internet-facing reverse proxy or is deployed in the DMZ.
Secure Shell (SSH) management Inbound/
Outbound
TCP/SSH 22 Optional. This port carries internal SSH access to each node for accessing the Access Gateway Management console. By default, access to the Access Gateway Management console is only allowed using the virtual environment console. Okta recommends that you don't open port 22 to general internet traffic.
Access Gateway High Availability Inbound/
Outbound
TCP/SSH 22 Internal bi-directional communication between Access Gateway nodes for configuration replication.
Access Gateway High Availability Worker to admin TCP/HTTPS 443 During initial configuration of high-availability Access Gateway worker instances, communicate using HTTPS over port 443 to the Access Gateway admin.
NTP Outbound UDP 123 Network time and date synchronization.
System Log Outbound System Log TCP Customer-supplied Event log forwarding to a log server product.
Access Gateway to the Key Distribution Center (KDC) Outbound TCP/UDP 88 Access Gateway communication with the Key Distribution Center (KDC).
Access Gateway to DNS Outbound TCP/UDP 53 Access Gateway communication with the DNS.

Application-specific access

Depending on how an application is configured, Access Gateway may require access to the following services and ports:

Description Direction Protocol Port
Access Gateway to the Data Store Outbound LDAP/ODBC Customer-supplied (for example, 389/636)
Oracle E-Business Rapid SSO Outbound TCP/JDBC/SQL Customer-supplied (for example, 1521)

General site accessibility

The following URLs must be reachable from the Access Gateway appliance:

URL Description
yum.oag.okta.com Update support
www.okta.com Network testing
{client org}.okta.com Client-specific Okta org

Front-end load balancer requirements

If Access Gateway is installed in a high-availability configuration, your organization must provide a load balancer to manage the traffic. You can use either the Source Network Address Translation (SNAT) or Dynamic Network Address Translation (DNAT) protocols. Configure the load balancer to balance through a hash of the source port and IP address. See Example architecture and Load balancers.