This page applies to Appian Cloud only. It may not reflect the differences with Appian Government Cloud.
Customers who are subscribed to Basic Support cannot connect to resources in a self-managed network or in a private cloud environment.
You can use the Self Service VPN feature if you are configuring your first VPN tunnel in your Appian Cloud site. See Self Service VPN Integration.
IPsec VPN connections can be configured to allow your Appian Cloud environments(s) to access resources in your private network. Each Appian Cloud environment can have multiple VPN tunnels enabled to securely integrate with resources in different segments of your network. This enables the use of Appian Smart Services such as "Query Database" or "Web Service" to connect to resources located on your private network. VPN tunnels can also be used to secure connection to business datasources through the Admin Console, as well as integrate with corporate authentication systems (e.g. Active Directory).
Appian Cloud supports both Static and Dynamic Routing using IPsec VPN tunnels. For more specifics on dynamic VPN routing, visit our documentation on it.
Appian Cloud instances can have a pair of VPN tunnels configured as active/passive to failover between two (2) customer VPN gateways. Failover to the passive tunnel will be attempted upon failure of a ping test against a single IP address within your private network. This IP address must be reachable and ping must be enabled from both of your VPN gateways. We strongly recommend that you implement failover for your production instances. In order to simplify failover and reduce setup complexity, we recommend the use of Dynamic VPN Routing.
Static VPN tunnels are associated with a single Appian Cloud instance. This means that a typical static VPN integration on a High Availability environment will require 3 VPN tunnels. With failover, this would result in 6 VPN tunnels. In order to have a more robust setup for High Availability instances, we recommend the use of Dynamic VPN Routing.
Static VPN failover expects both sides of the connection to be automatic. Please make sure that your passive tunnel is configured to automatically start if the active tunnel becomes unavailable.
In order to use the VPN tunnel to connect to a resource on a private network, refer to the resource using its Fully Qualified Domain Name (FQDN) in any location where Appian allows the use of a URL for a resource, such as the Call Web Service or the Query Database smart services.
By default, Appian Cloud instances receive all web inbound traffic through the public Internet. Upon request, Appian can configure Appian Cloud instances to require web traffic to go through a VPN tunnel. With this configuration, the site will not be accessible over the Internet and all users must first be on their corporate network before navigating to their Appian Cloud instances. See Configuring Inbound Traffic over VPN for details.
Alternatively, you can also request your Appian Cloud instances to be configured in dual mode in which their instances receive inbound web traffic over the Internet and the VPN tunnel. See Configuring Dual Inbound Access for details on how to set up your instances in dual mode.
Both of these custom configurations require additional network hops for web traffic to enter Appian Cloud. You should take into consideration and carefully evaluate performance, as well as compatibility with mobile devices, if you wish to enable either of them.
Traffic addressed to a host within your corporate domain and for which the DNS lookup (from the corporate DNS servers if provided, otherwise the Internet) returns a private IP address (RFC 1918) is sent over the VPN tunnel. Appian Technical Support can configure traffic to certain public IP addresses to also be sent over the VPN tunnel if requested. All other traffic will be sent over the Internet.
This is applicable even if an Appian Cloud instance is configured to require all inbound traffic to go through the VPN tunnel.
Appian Cloud static VPNs use policy based VPNs, your device should be configured to support that. If the VPN gateway goes down, Appian cannot connect to resources located on your network. We strongly recommend that you take this into account when designing your Appian applications. For example, build the appropriate error handling and recovery mechanisms within your process models.
The VPN tunnels are set up so that either side can initiate the connection. We may disconnect the Appian Cloud instance during scheduled maintenance windows.
In the example below, you may integrate with the resources in your Private Network over a VPN tunnel by specifying the IP addresses within your Appian Environment. Please note that in this case, your Private Network Address space must not be in our reserved ranges.
DNS-based VPN routing allows you to reference your resources by specifying their FQDNs. We will conduct a DNS lookup on these FQDNs based on your specified DNS servers. You can use the Self Service VPN feature to add, modify, or remove DNS configurations.
When using DNS-based VPN Routing with Dynamic VPN Routing, the resolved IP addresses must not be in Appian's reserved ranges.
You may use any vendors that support IPsec VPN tunnels. Cloud providers who offer managed VPN instances can also be utilized as long as they support IPsec VPN tunnels. View the FAQ section for more specific examples of Cloud provider integrations.
To set up a VPN connection between your Appian Cloud instance(s) and your private network, download the Appian Cloud VPN worksheet.
Complete the sections in marked in yellow on the form and submit it to Appian Technical Support, creating a new case for your organization.
Reserved Private Network Address spaces may vary based on the region of your Appian Cloud environment(s). Typically, network spaces in the 192.* range are unrestricted, while certain subnets within the 172.16.0.0/12 and 10.0.0.0/8 ranges are restricted. Contact Appian Support to verify the restricted spaces for your specific Appian Cloud environment(s) if you would like to use subnets in these ranges. When configuring your private network space participating in the VPN tunnel, we recommend to narrow down your subnets as much as possible.
Alternatively, you can utilize NAT on your network to expose your private subnets in a different range and/or, for static VPN tunnels, you can utilize DNS-based VPN routing.
The following combinations of encryption configurations are supported for your VPN tunnels.
|Encryption algorithm||Authentication algorithm||DH Group|
|AES128-CBC||SHA2-256 or SHA2-384 or SHA2-512||DH15 or DH16 or DH17 or DH18 or DH19 or DH20 or DH21|
|AES256-CBC||SHA2-256 or SHA2-384 or SHA2-512||DH21|
|AES128-GCM||N/A||DH15 or DH16 or DH17 or DH18 or DH19 or DH20 or DH21|
The supported encryption configurations are set to ensure the security of your VPN tunnels. Other encryption configurations are deprecated and will be removed in a future release.
Yes, AWS provides connection options that are compatible with Appian Cloud VPN integration. Specifically, reference the AWS documentation on Site-to-site VPN Routing.
Yes, you can create a VPN attachment to your Transit Gateway hosted on your AWS account. You can then use the resulting Site-to-Site VPN connection resource to establish a tunnel to your Appian Cloud instance. Please reference the AWS public documentation on VPN attachments to Transit Gateway for more details.
No, Appian Cloud uses a third party software VPN appliance (LibreSwan) to establish a VPN connection to your remote network.
In order to ensure that IP addresses do not conflict with other Appian internal resources, the two subnets have been allocated for VPN configurations.
Contact Appian Support if there are any concerns or conflicts associated with those subnets.
On This Page