PingOne Advanced Services

Advanced network

The Advanced network option is designed for the most sophisticated networking needs. You connect to your on-premise and cloud-based environments using a secure, private connection, and there is no limit to the number of connections you can have.

With this type of network model, an extension of your network is created and deployed in the private IP space and is fully routable within your network. This option also supports all protocols that will allow you to design a network that meets the unique needs of your organization.

This option is best if you:

  • Have multiple data center connections using AWS Site-to-Site VPN or AWS Direct Connect.

  • Have multi-cloud connections in your tenant using AWS Site-to-Site VPN, or have dedicated interconnectivity provided by third-party providers to AWS and other cloud environments (Azure, GCP, and Oracle Cloud).

  • Use Kerberos and Radius protocols.

  • Have redundant connectivity in their cloud or on-premise data centers.

  • Require greater amounts of bandwidth than is typically available on a VPN network. Review the IP requirements.

There are several different types of Advanced network options available:

IP requirements

Because of its fully routable nature, the IP requirements will be greater for the Advanced network model than a Simple VPN model. Each VPC deployed in PingOne Advanced Services will require a /22 network CIDR assigned to it from your RFC1918 IP space. The exact number of IPs you will need will vary and depend on the types of environments you have.

Keep in mind that Ping Identity is not just deploying servers into AWS. Each VPN is a self-contained full data center with all the components that go along with it.

Environments required for all deployments:

  • Primary production environment

  • Primary development environment

  • Primary customer hub environment

  • Primary staging environment if a child region is also being deployed

Optional environments:

  • Primary testing environment

  • Primary staging environment for a single region

Learn more in Environments.

If you need a secondary customer hub environment, a secondary staging environment is required if a child region is also being deployed, but a secondary production environment is not. The same is true if you need a tertiary customer hub environment. A tertiary staging environment is required if a child region is also being deployed, but a tertiary production environment is not.

These environments are required because they’re needed to handle increases in AWS services and the number of endpoints used, and to provide the elasticity needed to autoscale the environment to meet traffic demands. You can specify which /22 network CIDR goes to each environment, or leave it up to your implementation partners to make these decisions when they build the environments.

Direct Connect (DX) network

The Direct Connect (DX) network uses DX to connect to you or to a global mesh network. Your network traffic remains on the AWS global network and never touches the public internet.

Unlike other network options that can have many different vendors involved, you purchase your connection directly from DX. AWS also maintains a list of AWS Direct Connect Delivery Partners, who can help you establish your connections.

This option is best if:

  • You want to improve application performance by connecting directly to AWS and bypassing the public internet.

  • You want to secure your data as it moves between your network and AWS with multiple encryption options.

  • You are willing to cover the cost of the connection, which will vary depending on the agreement made with your DX partners. PingOne Advanced Services receives the virtual interfaces (VIFs) for the AWS services included, but does not maintain the connection.

Learn more in AWS Direct Connect in the Amazon documentation.

DX network diagram
Diagram of a DX network.

Learn more about items you might need to consider regarding set up in Setup considerations.

Transit Gateway (TGW) network

If you have your own AWS presence but need a connection method that can support Kerberos and Radius protocols, which PrivateLink cannot, the Transit Gateway (TGW) network might be the right option for you.

There are two different types of TGW networks:

TGW peering network

With this model, the TGW peers to the TGW in the customer hub environment in PingOne Advanced Services. Traffic from all environments in a PingOne Advanced Services region will travel across this peering connection.

TGW peering network diagram
Diagram of a TGW peering network.

Learn more about items you might need to consider regarding setup in Setup considerations.

TGW RAM share network

With this model, the TGW is connected to each VPC instead using the customer hub environment, which allows for data separation.

TGW RAM share network diagram
Diagram of a TGW RAM share network.

Learn more about items you might need to consider regarding setup in Setup considerations.

VPN network

VPNs are typically used in advanced network situations where you need to connect to an on-premise infrastructure, and a large amount of bandwidth is not required. Although you can make the same type of connection with a Direct Connect (DC) network, which offers more bandwidth, the cost of the connection is separate from PingOne Advanced Services.

You can also set up as many VPN connections as you need. Border Gateway Protocol (BGP) and static routing are both supported. If BGP is used, we’ll ask that you share your routes. PingOne Advanced Services is designed in the hub-and-spoke model, which does not allow routes to propagate to the VPCs behind the Transit Gateway.

This option is best if you:

  • Need to connect to an on-premise infrastructure.

  • Do not need a large amount of bandwidth.

  • Do not want to cover the cost of having this connection.

This network model uses the AWS VPN service, which is a route-based solution. For details regarding this connection:

  • Learn more about Appliances in Customer Gateway Configuration Formats.

  • Learn more about VPN settings in Tunnel options for your Site-to-Site VPN connection in the AWS Site-to-Site VPN User Guide.

  • A Site-to-Site VPN connection consists of two tunnels, each terminating in a different availability zone, to provide increased availability to your VPC. If there’s a device failure within AWS, your VPN connection automatically fails over to the second tunnel so that your access isn’t interrupted. From time to time, AWS also performs routine maintenance on your VPN connection, which might briefly disable one of the two tunnels of your VPN connection, which is why it’s important to configure both tunnels. Learn more about tunnel resiliency in Site-to-Site VPN tunnel endpoint replacements.

If a gateway device terminating the VPN tunnels uses policy-based routing:

  • Each VPN connection consists of two separate tunnels.

  • Each tunnel contains an IKE security association and a BGP peering connection.

  • You are limited to one unique security association (SA) pair per tunnel, (one inbound and one outbound).

This limitation requires that each PingOne Advanced Services region uses IP space that does not overlap and can be summarized into a single supernet to allow for a single SA per region VPN.

Learn more about VPN networks in Your customer gateway device in the AWS Site-to-Site VPN User Guide.

VPN network diagram
Diagram of a VPN network.

Learn more about items you might need to consider regarding setup in Setup considerations.

Advanced network endpoints

Public and private endpoints for the Advanced network model are listed here.

Default public endpoints
Default public endpoints URLs

PingAccess

https://pingaccess.{environment}-{customer}.{region}.ping.cloud/

PingFederate

https://pingfederate.{environment}-{customer}.{region}.ping.cloud/

Environment logs

https://logs.{environment}-{customer}.{region}.ping.cloud/

Environment monitoring

https://monitoring.{environment}-{customer}.{region}.ping.cloud/

PingFederate admin console

https://pingfederate-admin.{environment}-{customer}.{region}.ping.cloud/

PingAccess admin console

https://pingaccess-admin.{environment}-{customer}.{region}.ping.cloud/

PingCentral

https://pingcentral-admin.{customer}.{region}.ping.cloud/

Optional public endpoints
Optional public endpoints URLs

PingFederate admin API

https://ext-pingfederate-admin-api.{environment}-{customer}.{region}.ping.cloud

PingAccess admin API

https://ext-pingaccess-admin-api.{environment}-{customer}.{region}.ping.cloud

PingDirectory

PingDirectory LDAPS endpoints must be on the allowed list on the PingDirectory connection handler.

ldaps://ext-pingdirectory-admin.{environment}-{customer}.{region}.ping.cloud

PingDirectory API

https://ext-pingdirectory.{environment}-{customer}.{region}.ping.cloud

PingDelegator

https://ext-pingdelegator.{environment}-{customer}.{region}.ping.cloud

PingFederate global (multi-region only)

https://pf.{environment}.global.{customer}.ping.cloud

PingAccess global (multi-region only)

https://pa.{environment}.global.{customer}.ping.cloud

Default private endpoints
Default private endpoints URLs

PingFederate admin API

https://pingfederate-admin-api.{environment}-{customer}.{region}.ping.cloud/

PingAccess admin API

https://pingaccess-admin-api.{environment}-{customer}.{region}.ping.cloud/

PingDirectory

PingDirectory LDAPS endpoints must be on the allowed list on the PingDirectory connection handler.

ldaps://pingdirectory-admin.{environment}-{customer}.{region}.ping.cloud/

PingDirectory API

https://pingdirectory.{environment}-{customer}.{region}.ping.cloud

PingDelegator

https://pingdelegator.{environment}-{customer}.{region}.ping.cloud/

Optional private endpoints
Optional private endpoints URLs

PingDataSync

ldaps://pingdatasync-admin.{environment}-{customer}.{region}.ping.cloud

PingDirectory

ldaps://pingdirectory-sync.{environment}-{customer}.{region}.ping.cloud