如何配置StrongSwan IPsec站点到站点PSK VPN？解决连接一直CONNECTING问题

Let's sort out your IPsec site-to-site VPN configuration step by step. Based on the specs you provided (PSK auth, AES-256 encryption, SHA hashing, DH group 2, server IP xx.45.40.46), here's a corrected setup for ipsec.conf, plus the necessary ipsec.secrets configuration and tips to fix that stuck "CONNECTING" state.

Replace your current config with this (adjust the left/right subnet details to match your local and remote networks):

# Basic IPsec configuration
config setup
    charondebug="ike 2, knl 2, cfg 2"  # Enable debug logs for troubleshooting
    uniqueids=yes

# Site-to-site VPN connection definition
conn aws-to-otherplace
    left=%defaultroute  # Local side (your end) uses default route
    leftsubnet=192.168.1.0/24  # Replace with YOUR local subnet
    right=xx.45.40.46  # VPN server IP you provided
    rightsubnet=10.0.0.0/24  # Replace with REMOTE server's subnet
    ike=aes256-sha1-modp1024!  # IKE phase 1: AES-256, SHA-1, DH group 2 (modp1024)
    esp=aes256-sha1!  # IKE phase 2: AES-256, SHA-1
    keyexchange=ikev1  # Use IKEv1 (DH group 2 is commonly paired with IKEv1)
    authby=secret  # Enable PSK authentication
    auto=start  # Auto-attempt connection when ipsec starts
    ikelifetime=86400s  # IKE phase 1 lifetime (1 day)
    keylife=3600s  # IKE phase 2 lifetime (1 hour)
    rekey=yes  # Automatically rekey when lifetime expires

Key Parameter Breakdown: #

• ike=aes256-sha1-modp1024!: Forces IKE phase 1 to use exactly your specified algorithms—AES-256 encryption, SHA-1 hashing, and DH group 2 (marked as modp1024). The ! ensures no fallback to weaker protocols.
• esp=aes256-sha1!: Matches your encryption/hashing requirements for the data transfer phase (IKE phase 2).
• authby=secret: Explicitly enables PSK-based authentication, aligning with your requirement.
• left=%defaultroute: Uses your local machine's default network interface for the VPN. If you need a specific interface, replace this with something like left=eth0.
• auto=start: Ensures the connection tries to establish as soon as you run ipsec start.

Your ipsec.secrets file must contain the matching PSK for the VPN server. Add this line (replace your_strong_pre_shared_key_here with the actual shared key):

xx.45.40.46 : PSK "your_strong_pre_shared_key_here"

Lock down the file's permissions to prevent unauthorized access:

chmod 600 /etc/ipsec.secrets

If the connection stays stuck in CONNECTING after applying the config, try these troubleshooting steps:

• Check basic connectivity: Ping the VPN server (ping xx.45.40.46) to confirm your machine can reach it. If ping fails, resolve firewall or routing issues first.
• Verify open ports: Ensure UDP ports 500 (IKE) and 4500 (NAT-T) are open on both your local machine and the VPN server. Test with nc -uvz xx.45.40.46 500 and nc -uvz xx.45.40.46 4500.
• Confirm PSK consistency: Double-check that the PSK in ipsec.secrets is exactly the same as what's configured on the VPN server—even a single typo will break authentication.
• Dig into debug logs: Run ipsec statusall for detailed connection status, or journalctl -u strongswan (if using StrongSwan) to spot errors like mismatched algorithms or authentication failures.
• Validate subnet settings: Ensure leftsubnet and rightsubnet correctly reflect your local and remote networks—mismatched subnets can prevent the connection from completing.

After making changes, restart the IPsec service with ipsec restart and check the status again with ipsec status aws-to-otherplace.

内容的提问来源于stack exchange，提问作者Fred joe