Customer VPN Form
1. Requirements from the Customer
The customer is responsible for providing the configuration details of their local VPN gateway and ensuring their internal network is ready for the connection.
Network & Device Information
-
VPN Device Details: Manufacturer, model, and version of the local VPN device (e.g., Cisco, Palo Alto, Checkpoint).
-
Public Peer IP: The public-facing IP address of the customer's VPN gateway.
-
Local Subnets: The specific internal IP ranges (CIDRs) that need to communicate across the VPN.
-
Restricted Ranges: The customer must ensure their local IPs do not overlap with Rhapsody’s restricted blocks:
172.16.128.0/18,10.130.0.0/16, and10.140.0.0/16.
Phase 1 & Phase 2 Security Settings
The customer must specify or agree to the following encryption standards to ensure the "handshake" between devices succeeds:
-
IKE Version: Support for IKEv2 (default) or IKEv1.
-
Encryption & Hash: Selection of algorithms such as AES-GCM-256 and SHA2-512.
-
Diffie-Hellman (DH) Group: Selection of a group (Groups 14–24 are default).
-
Lifetimes: Setting Phase 1 lifetime (900–28,800s) and Phase 2 lifetime (900–3,600s), ensuring Phase 1 is longer.
Firewall & Connectivity
The customer must configure their local firewall to allow the following traffic to/from the Azure VPN Gateway:
-
UDP 500 (IKE).
-
UDP 4500 (IPsec NAT-T).
-
IP Protocol 50 (ESP).
2. What This Process Does
This form ensures that both sides of the VPN tunnel are "speaking the same language" so that data can be encrypted and transmitted securely.
-
Creates a Secure Tunnel: Established an encrypted IPsec tunnel over the public internet to allow private communication between the customer's site and Rhapsody.
-
Defines the "Encryption Domain": Identifies exactly which subnets are allowed to send traffic through the tunnel, preventing unauthorized network access.
-
Ensures High Availability: Accounts for Azure’s active-standby gateway pair, which provides automatic failover during maintenance or unexpected issues.
-
Maintains Connection Health: Utilizes Dead Peer Detection (DPD) and liveness checks to monitor the tunnel status and prevent it from closing due to inactivity.
-
Standardizes Troubleshooting: Provides a clear checklist for resolving "Phase 1" or "Phase 2" failures, such as mismatched lifetimes or incorrect security associations .