Site-to-Site VPN Guide¶
For organizations that don’t make available an external LDAPS connection, a site-to-site VPN is the best option for providing the LDAP access required to perform user integration with PolicyStat. Your organization will configure several IPSec Site-to-Site VPNs using your existing VPN infrastructure (Cisco, Nortel, etc).
This guide is a technical overview of:
- The purpose of the site-to-site VPN.
- The process for implementing and testing the VPN.
- The configuration details for the VPN.
Purpose of the VPN¶
Since LDAP is a plain-text protocol, we must provide transport encryption over the network. Barring LDAPS (secure LDAP) encryption, the IPSec tunnel created by a Site-to-Site VPN provides excellent security. To provide access at the least-privileged level possible, we recommend only allowing tunnel traffic from the specific internal NAT’d IP belonging to your LDAP endpoint to the public IP of PolicyStat’s server. All traffic between the two involved endpoints will then flow over the secure IPSec tunnel.
For High Availability purposes, we will configure six separate VPN tunnels, one for each of the PolicyStat IP Addresses.
VPN Implementation Process¶
In general, the process for establishing VPN connectivity looks like this:
- We agree on the configuration details for the IPSec tunnel.
- We securely exchange a Pre-Shared Key (PSK).
- PolicyStat configures its side of the tunnel.
- You configure your six tunnels and appropriate firewall rules.
- If necessary, we work together to troubleshoot any connectivity problems using logging and test connections.
NOTE: If a VPN service requires updates or reconfiguration, please be aware and take into account that the configuration process will require at minimum 2 business days for our team to complete.
The configuration screens and option names vary by vendor and version, so the options here are labeled according to IPSec conventions, which is the technology underlying each vendor’s specific site to site VPN implementation. If any of these terms are ambiguous relative to the options you’re seeing, PolicyStat will work with you to clarify.
Since we will be creating six tunnels, one for each redundant PolicyStat IP address, the following examples use PolicyStatIP to represent the location where you’ll place the specific IP address.
These options are the defaults PolicyStat has reached to maximize interoperability and ease the setup process. If your organization would like to make changes, please let us know.
PolicyStat’s Peer IP Address¶
This is sometimes called the “Peer Identity”, “Security Gateway Address” and/or “Peer ID.”
For each of the six tunnels, use the PolicyStatIP.
If you have a separate configuration option for PolicyStat’s Peer ID, also use the PolicyStatIP.
Internet Key Exchange (IKE) policy¶
- Encryption: AES 256 bit
- Authentication: SHA1
- Diffie–Hellman (DH) Group: 14 or better
- IKE Version: 1 (IKEv2 is not supported)
- IKE Life: 3600 seconds
This is IKE (main mode) Key Exchange.
- Encryption: AES 256 bit
- Authentication: SHA1
- Enable Perfect Forwarding Secrecy (PFS): yes (DH Group- 14)
- NAT-T (NAT traversal): enabled
- Mode: Main mode
- IPSec Life: 28800 seconds
- Re-key Margin: 540 seconds
This is sometimes called an ESP Transform Set.
The internal (NAT’d) IP address of your LDAP server.
PolicyStat Remote Network
For each of the six tunnels, use the PolicyStat Remote Network.
Depending on your firewall configuration, you might also need to create an ACL allowing a connection from each of the PolicyStat servers to your NAT’d LDAP endpoint.
Your Peer ID for ISAKMP negotiation. It should match the public IP of your VPN endpoint.
For some VPN vendors, this option is auto-generated and hidden in sub-menus. It’s also sometimes called your “Local ID”
PolicyStat IP Addresses¶
LDAP connections from the following six IP addresses must be allowed for synchronization to occur. PolicyStat utilizes a geographically-redundant architecture, maintaining connections from two separate servers simultaneously. PolicyStat also provides beta and training versions of PolicyStat, along with the production version, to allow users to test new features and to train against a sandbox without affecting their production environment.
Beta environment (configure these first, for testing):
- Peer IP: 126.96.36.199
- Remote Network: 172.17.110.214/32
- Peer IP: 188.8.131.52
- Remote Network: 172.17.120.166/32
- Peer IP: 184.108.40.206
- Remote Network: 172.19.110.147/32
- Peer IP: 220.127.116.11
- Remote Network: 172.19.120.155/32
- Peer IP: 18.104.22.168
- Remote Network: 172.26.110.167/32
- Peer IP: 22.214.171.124
- Remote Network: 172.26.120.151/32
Depending on your firewall configuration, you will likely need to add exceptions to allow the PolicyStat servers to access your LDAP endpoint.
The default port for LDAP is 389, so if you’ve configured LDAP with default settings, you’ll need to add a firewall ACL allowing TCP/UDP on port 389.
Technically, LDAP is actually a TCP-only protocol, but Microsoft implements an LDAP Search over UDP option.
Troubleshooting Failure To Establish a TCP Socket¶
Sometimes, the VPN tunnel will succeed, but PolicyStat’s servers will be unable to connect to the LDAP Domain Controllers (DCs). To test connectivity, PolicyStat attempts to open a TCP socket against your LDAP DCs.
Debugging Connectivity Failure¶
In order to facilitate debugging, PolicyStat allows self-service initiation of both TCP socket requests and LDAP/LDAPS connections via the Active Directory Configuration page. You can do this by logging into your PolicyStat site with a user account that has Site Administrator permissions. You can choose to use your production environment or your sandboxed, training PolicyStat environment. If you do not have a PolicyStat account with appropriate access, please request one.
Once logged in:
- Navigate to the Admin tab
- Select Active Directory under the Configuration menu
- Ensure that the Server URI field contains the IP address of your LDAP DC.
- Click Test This Configuration to initiate a TCP socket request.
You can then monitor the appropriate logs (your firewall or VPN logs, most likely) and filter for an incoming request from one of the PolicyStat IP Addresses.
We recommend using logs to progressively debug each major link in the connectivity chain.
- Does the packet reach your VPN?
- Does the packet reach your firewall (sometimes your VPN is your firewall)?
- Does the packet reach the LDAP DC?
- Does the response packet reach the VPN?
Common Causes For Connectivity Failure¶
The following are common causes for an established VPN tunnel not allowing for network connectivity to the LDAP DCs:
1. LDAP DCs aren’t yet configured¶
If the LDAP DCs aren’t yet configured, then of course connectivity will fail. The solution here is to simply wait until the DCs are up and ready.
2. LDAP DCs have local firewall rules preventing the connection¶
The Windows Firewall running on the LDAP DCs must allow the connection.
3. VPN ACL doesn’t allow LDAP DCs Access¶
As part of the VPN configuration, some vendors require separate ACLs to provide access to the LDAP DCs from PolicyStat’s servers.
4. LDAP DCs lack route to VPN¶
The LDAP DCs must have network routing configuration that routes packets destined for the PolicyStat IP addresses through your VPN. In an environment where the default gateway is different from the VPN, that can mean a manual routing entry is required to ensure that the VPN receives the packet and is able to route it via the tunnel.