Exploring Virtual Private Network (VPN)

  • Release version: Australia
  • Updated May 15, 2026
  • 6 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Exploring Virtual Private Network (VPN)

    This guide explains how ServiceNow customers can use Virtual Private Network (VPN) connections to securely integrate their ServiceNow instances with external data sources over the Internet. VPNs provide encrypted communication channels between ServiceNow data centers and customer networks, primarily supporting site-to-site IPSEC connections. This setup is especially relevant when security or network architecture policies require encrypted tunnels between datacenters and business networks.

    Show full answer Show less

    Key Features

    • VPN Infrastructure: ServiceNow uses Cisco ASA devices to terminate VPNs, and supports integration with various IPSEC-capable hardware such as Checkpoint, Juniper, and Nortel. Customers do not need to install new hardware.
    • Traffic and Protocols: VPN tunnels are typically used for outbound encrypted traffic, especially when underlying protocols lack native encryption (e.g., LDAP over VPN versus LDAPS over the Internet). Importantly, inbound traffic to ServiceNow instances, including end-user access and administration, must occur over HTTPS directly via the Internet, not through VPN tunnels.
    • IP Addressing and NAT: VPN tunnels require non-RFC-1918 (public) IP addresses on both sides to avoid conflicts. ServiceNow assigns a single source IP for outbound queries, while customers must provide NAT addresses for integrated hosts owned by their organization.
    • Redundancy Options: Two redundancy methods are supported: using the same encryption domain across VPN peers (preferred for seamless failover) or using different domains with instance-level failover configuration. The first method is recommended for transparency and reliability.

    Best Practices and Alternatives

    • Security Considerations: VPN endpoints receive public IP addresses accessible by all instances in the same data center, so limiting the encryption domain to only necessary hosts is advised to minimize exposure and routing issues.
    • Alternatives to VPN: Customers are encouraged to consider Single Sign-On (SSO) combined with MID Servers for LDAP integration, which eliminates the need for firewall changes or VPN tunnels and supports near real-time user synchronization securely and cost-effectively.
    • LDAP over SSL (LDAPS): Another alternative is to use LDAPS directly over the Internet, providing strong end-to-end application layer encryption with certificate-based authentication, often preferable to VPN encryption based on pre-shared keys.

    VPN Setup and Support

    • VPN provisioning typically completes within one week after request submission.
    • ServiceNow provisions between two and four VPN tunnels to support redundancy and disaster recovery, connecting data centers to customer networks.
    • Encryption domains should be as narrow as possible, focusing only on specific hosts needed for integrations to avoid routing conflicts.
    • ServiceNow does not support multiple VPN tunnels for connecting to different geographic regions or subsidiaries; such routing should be managed internally by the customer.

    By following these guidelines, ServiceNow customers can securely and efficiently integrate their instances with external systems using VPNs or recommended alternatives, maintaining strong encryption and operational reliability.

    Use a virtual private network (VPN) to integrate your instance with external data sources over the Internet.

    When configuring an integration that uses an encrypted protocol, such as Lightweight Directory Access Protocol (LDAP) or HTTPS, it is good practice to use the Internet as a transport mechanism.

    However, there may be security or network architecture requirements that dictate the use of a site-to-site Internet Protocol Security (IPSEC) Virtual Private Network (VPN) connection between the datacenters and your business networks. The VPN supports the necessary encrypted communication between the instance and your network.

    Warning:

    When a VPN tunnel is initiated, it operates as site-to-site connection. This means that the endpoint on your infrastructure receives an IP address, referred to as an encryption domain. This public IP can be accessed by any instance within the same data center.

    For example, if you have an internal web service and establishes a VPN tunnel, your instance is able to reach the internal endpoint as well as all your other instances in the same data center.

    VPN connections

    The ServiceNow VPN infrastructure uses pairs of Cisco adaptive security appliance (ASA) devices that serve as VPN termination points.

    The VPN between the instance and your network utilizes your existing networking hardware to support communications. It is not necessary to install a piece of hardware. Because each customer has a unique configuration, the instance has a flexible VPN solution. the instance has built tunnels to Checkpoint, Juniper, Nortel, and other IPSEC VPN-capable devices.

    The VPN connections between the instance and your network are created to support the encrypted flow of traffic into your network. Frequently, integrations that use the VPN do not have encryption as part of the underlying protocol. For example, LDAP over the VPN versus LDAPS over the Internet and HTTP over the VPN versus HTTPS over the Internet.

    The network does not allow any inbound-to-ServiceNow integration or end-user-to-ServiceNow traffic to traverse a VPN connection. This restricted communication includes end-user access to the platform, administration of the platform, web services integrations, and other integrations that are configured to use a MID Server. All such inbound communication to the instance must be performed over the Internet using HTTPS. This configuration provides an encrypted communication channel. The encryption channel, along with IP access control, meets the security requirements for this traffic flow.

    This restriction applies to inbound traffic only. Responses to outbound requests that the instance initiates do traverse the VPN tunnel.

    Addresses for VPN communication

    To prevent conflict or overlap with internal ServiceNow networks or with another internal IP address schemes in your network, all tunneled traffic in the encryption domain must use non-RFC-1918 addresses on both sides of the tunnel.

    ServiceNow provides a single IP address for the source of queries into your network. You must provide Network Address Translation (NAT), non-RFC-1918 addresses for each host that is integrating with your instance. These public addresses need to be owned by your organization. Third-party addresses cannot be used inside tunnels. Additionally, the encryption domain must not contain the IP address of the VPN peer.

    Redundant tunnels

    There are two ways to build redundancy for your tunnels:
    • Using the same encryption domain behind both of your peers. This is the preferred method.
    • Using a different encryption domain behind each peer.

    With the first method, you need to provide the same NAT address behind each of your peers to create a connection path using that address to your server. The path to your server could be the same physical machine or a mirror which provides identical services. With this method, your instance would use the same IP address to connect to your servers regardless of whether your primary or secondary tunnel is active. If you have more than one server, follow this same scheme for your additional servers. This method provides the most transparency to your users and is recommended.

    The second method requires configuration in your instance to provide the redundancy. When the tunnel is used for LDAP, for example, you could provide redundant LDAP servers in your instance. Note that this method requires the connection to the first configured LDAP server to timeout before the instance attempts to connect to the secondary server. Because of this additional time delay, this solution should only be implemented if the first option is unattainable. Also note that not all services can be configured for redundantly in your instance. If you are using a VPN tunnel for something other than LDAP and redundancy is required, check that your configuration can support multiple addresses, or see the first option above.

    Alternatives to using a VPN

    These alternatives provide a simpler way to connect your instance to the resources in the ServiceNow data centers and provide better encryption. Additionally, you can avoid any issues that VPN downtime might cause, such as making your instance unavailable to users if there is an issue with the VPN tunnel.

    Single sign-on and MID server

    Consider using a combination of Single Sign-On (SSO) for authentication and the MID Server for user data synchronization, rather than using a VPN to connect your LDAP server to your instance. For integrations other than LDAP, consider using certificate-based encryption.

    You can use the LDAP listener on a MID server to synchronize your user table in near real time.

    The advantage of this approach is that there are no firewall holes, routes, VPN tunnels, or other special network settings to configure and maintain. The SSO/MID-Server solution is the most flexible, secure, and cost-effective method to achieve the complete LDAP integration.

    LDAP over SSL
    Another alternative to using a VPN tunnel is to configure LDAP Over SSL (LDAPS) directly over the Internet. You can configure a read-only domain controller and lock the instance down in your DMZ using only the instance's source addresses and the destination ports of your choice. Since the ports for LDAP are configurable in your instance, you can perform a port address translation (PAT) if desired. With LDAPS, you control the certificate that is uploaded over an encrypted channel to the instance, (see Uploading a certificate to an instance). The packets cannot be encrypted or decrypted without the certificate.

    The advantage of this approach is that it provides a stronger encryption and decryption mechanism. A VPN can only encrypt and decrypt the traffic between the two peers sitting on the Internet with a coordinated pre-shared key, similar to a password. LDAPS provides a longer encrypted path, end-to-end, at the application layer and with a certificate that is far more complicated than a pre-shared key that the IPSec tunnel uses.

    VPN setup

    From the time that a VPN request is submitted, it typically takes one week or less to complete the VPN build. To support the redundancy requirements of your instance and your organization, a minimum of two and a maximum of four VPNs are provisioned (from the active site to your active site or the active site to your DR site, and so on).

    It is good practice for the encryption domain to be as specific as possible. Ideally, the encryption domain would include only the specific hosts that are required for the integrations. A large encryption domain can create opportunities for routing discrepancies (VPN versus Internet).

    To create the VPN, the instance does the following:
    1. Provides the VPN peer and host addresses from each data center.
    2. Builds the necessary VPN connectivity from two data centers into your network. To support redundancy and disaster recovery (DR) requirements, the VPNs can be provisioned from two data centers into two networks.

    The instance does not support building multiple VPN tunnels into a customer network for the purpose of connecting to multiple geographic regions or subsidiaries. You should perform any inter-site routing, traffic distribution, or traffic shaping within your own internal network, rather than having multiple VPN tunnels.