Skip to main content
kaushal.patel
kaushal.patel
Employee
October 19, 2026

KB-2415 How to resolve vendor-specific VPN issues for Appian Cloud sites

Purpose

This article describes vendor-specific Virtual Private Network (VPN) issues and sticking points that Appian has observed with Appian Cloud sites. It covers setup considerations and troubleshooting guidance for Cisco, Palo Alto, AWS Site-to-Site VPN, and Azure. The information may not reflect the latest vendor approaches or current best practices; please engage the applicable VPN vendor support for any questions or guidance on implementation.

Instructions

The sections below are organized by each respective VPN vendor. Each vendor section includes setup considerations followed by symptoms and their potential causes or fixes. Appian offers a Static VPN (policy-based) and a Dynamic VPN (route-based through BGP peering). For a comparison of the two offerings, see Comparison of Static vs Dynamic VPN.

 

Table of Contents:

Cisco

Setup Considerations

  • For customers using the Static VPN offering, the Access Control List (ACL) should match the subnets configured for the VPN tunnel. Each Appian Cloud environment that uses VPN tunnels should be configured as a separate ACL.

Troubleshooting

  • Symptom: The VPN tunnel drops on a consistent interval.
    • Potential Cause / Fix: Cisco devices have multiple timeout and limit settings in their configuration (for example, vpn-idle-timeout, vpn-session-timeout, and lifetime kilobytes). Review these properties, because the tunnel drops and the connection is lost when a configured limit is reached.
  • Symptom: The VPN tunnel fails to negotiate successfully or has extended downtime during re-keying.
    • Potential Cause / Fix: Cisco devices can be very sensitive to Access Control Lists. The ACL should match the subnets configured for the VPN tunnel, and each Appian Cloud environment that uses VPN tunnels should be configured as a separate ACL.

Palo Alto

Setup Considerations

  • For customers using the Static VPN offering: Appian's Static VPN offering uses policy-based VPN. Palo Alto's documentation indicates that it does not support policy-based VPNs; however, Proxy-IDs may be used to establish connectivity with policy-based VPN configurations.
  • For customers looking for an alternative to policy-based VPN, Appian's Dynamic VPN offering supports route-based VPN through BGP peering.

Troubleshooting

  • Symptom: The Static VPN tunnel fails to negotiate Phase 1 successfully.
    • Potential Cause / Fix: Appian's Static VPN offering uses policy-based VPN. Palo Alto's documentation indicates that it does not support policy-based VPNs; however, Proxy-IDs may be used to establish connectivity. Confirm that Proxy-IDs are configured and exactly match the subnets configured by Appian.
  • Symptom: The VPN tunnel is unexpectedly restarting.
    • Potential Cause / Fix: Palo Alto has a proprietary Tunnel Monitoring system beyond Dead Peer Detection (DPD) that sends additional heartbeat traffic across the tunnel. Depending on how Tunnel Monitoring is configured, these packets can be misconstrued as negotiation attempts and result in the tunnel restarting or negotiating unsuccessfully.

AWS Site-to-Site VPN

Setup Considerations

  • For customers using the Static VPN offering: Appian's Static VPN offering uses policy-based VPN. AWS Site-to-Site VPN uses route-based VPN.
  • For customers looking for an alternative to policy-based VPN, Appian's Dynamic VPN offering supports route-based VPN through BGP peering.
  • For customers using the Dynamic VPN offering, Appian requires an Active-Passive tunnel configuration. Active-Active is not supported. The primary and secondary tunnels may not share the same Gateway IP.
  • For customers using the Dynamic VPN offering, Appian's Dynamic VPN requires an active-passive tunnel configuration. Active-Active is not supported. Because Appian provides two distinct gateway IP addresses, the customer must create two separate AWS Site-to-Site VPN connections, each associated with an AWS Customer Gateway configured with the corresponding Appian gateway IP.
    • For this Appian setup, the customer uses only the primary tunnel (Tunnel 1) from each AWS VPN connection:
      • AWS VPN connection 1, Tunnel 1: Connects to Appian's primary (active) gateway.
      • AWS VPN connection 2, Tunnel 1: Connects to Appian's secondary (passive) gateway.
    • Tunnel 2 within each AWS VPN connection remains unused in this configuration. Appian's active-passive pair therefore spans two separate AWS VPN connections.

Troubleshooting

  • Symptom: A Static VPN tunnel with multiple subnets only intermittently passes traffic.
    • Potential Cause / Fix: Appian's Static VPN offering uses policy-based VPN, while AWS Site-to-Site VPN uses route-based VPN. When Appian attempts to negotiate multiple Security Associations, AWS may negotiate only one. When traffic is sent to the tunnel, it may not be marked with the correct Security Association and is dropped. Consider the following options:
      • Consolidate subnets to a single subnet per tunnel.
      • Move from Appian's Static VPN offering to the Dynamic VPN offering, which supports route-based tunnels.
      • If neither option is possible for the setup, reach out to Appian Support via MyAppian to review whether other alternatives are possible.
  • Symptom: BGP peer sessions fail to be established for a Dynamic VPN.
    • Potential Cause / Fix: AWS Site-to-Site VPN assigns the first usable IP address in the selected APIPA /30 range to its own BGP peer. The other endpoint must use the second usable IP address. If the respective configuration on the Cloud Self-Service VPN (SSVPN) portal is configured with these assignments reversed, the BGP session will not be established.
      Update the BGP peer configuration in the SSVPN portal, so that the Appian peer uses the second usable IP address and the customer's AWS peer uses the first usable IP address. Verify that both values match the AWS tunnel configuration. For example, with 169.254.10.0/30, the customer's AWS peer would use 169.254.10.1, and the Appian peer would use 169.254.10.2.

 

Azure

Setup Considerations

  • For customers using the Static VPN offering: Appian's Static VPN offering uses policy-based VPN. Azure's documentation indicates that it does not support policy-based VPNs; however, PolicyBasedTrafficSelectors may be used to establish connectivity with policy-based VPN configurations.
  • Azure's PolicyBasedTrafficSelectors are not compatible with Azure's NAT functionality. If NAT is required in the configuration, such as for connection to resources in Appian's restricted range without using DNS-based routing, then alternatives to a Static VPN tunnel should be considered.
  • For customers looking for an alternative to Static / policy-based VPN, Appian's Dynamic VPN offering supports route-based VPN through BGP peering.
  • For customers using the Dynamic VPN offering, Appian requires an Active-Passive tunnel configuration. Active-Active is not supported. The primary and secondary tunnels may not share the same Gateway IP.

Troubleshooting

  • Symptom: A Static VPN will not negotiate successfully, with error messages such as INVALID_IKE_SPI or mentioning a Traffic Selector mismatch.
    • Potential Cause / Fix: Appian's Static VPN offering uses policy-based VPN. Azure's documentation indicates that it does not support policy-based VPNs; however, PolicyBasedTrafficSelectors may be used to establish connectivity. Azure's PolicyBasedTrafficSelectors are not compatible with Azure's NAT functionality.
      • Confirm that PolicyBasedTrafficSelectors are configured and match the subnet configured in Appian.
      • If PolicyBasedTrafficSelectors cannot be configured because of NAT requirements, consider alternatives such as moving from Appian's Static VPN offering to the Dynamic VPN offering, which supports route-based tunnels.

Affected Versions

This article applies to all versions of Appian Cloud.

 

Last Reviewed: October 2026

 

    Terms & ConditionsAccessibility statement