Setting Up an IKEv2 Tunnel Without Installing a Client to Bypass Cursor's Regional Restrictions

(Thanks to Koutian Wu for thoroughly debugging and deploying, and for pointing out several technical issues in the original article, which have been corrected in this version)

As access to tools like Cursor and Claude Code becomes restricted in China, traditional HTTP/SOCKS proxies can no longer meet daily needs. These tools not only impose regional restrictions on the server side but may also employ multi-layered techniques to detect the user’s true geographical location (currently only partially implemented, but may be upgraded in the future):

Basic IP Database Matching: Traditional GeoIP database queries
Timezone Consistency Check: Obtaining the client’s timezone via JavaScript and cross-verifying with the IP’s geographical location
DNS Resolution Check: Using Geo DNS resolution results to check the real location
WebRTC IP Leak Detection: Obtaining the user’s real IP address via WebRTC
CloudFlare Source Address Retrieval: Obtaining the real source address through CloudFlare’s HTTP headers

Most current HTTP/SOCKS proxies can only handle basic detection methods, while more complex multi-dimensional detection often leaves them powerless. A three-layer tunnel, working at the network layer, can more thoroughly hide the user’s real network environment.

Besides bypassing geographical restrictions, a three-layer tunnel is also suitable for the following scenarios:

Server Access Control: Avoid exposing the SSH access port of company servers on the public internet
Development and Testing Environment: Avoid exposing the company’s test servers, internal APIs, etc., on the public internet
Secure Network Environment: Ensure communication security in untrusted public WiFi environments

While solutions like WireGuard and OpenVPN are stable and efficient, they require installing dedicated clients, which can be cumbersome in multi-device usage scenarios.

IKEv2, as a modern VPN standard, not only offers excellent performance and stability but, more importantly, is natively integrated into mainstream operating systems like macOS, Windows, iOS, and Android, eliminating the need to install any third-party clients.

This article will build on the architecture idea from “Skillfully Using Hong Kong as a Relay to Build a Smooth and Stable China-US Three-Layer Tunnel“ to construct a China -> Hong Kong -> USA IKEv2 tunnel three-hop solution.

Architecture Design

To bypass complex geographical detection and ensure stable and fast connections, we designed not a simple point-to-point tunnel but a “three-hop” architecture.

We will set up the following data link:

Your Device (IKEv2) → Domestic Server (Xray) → Hong Kong Server (Nginx + Xray) → US Server (strongSwan) → Internet

+--------------------------+
|        Your Device       |
|  (Native IKEv2 Client)   |
+--------------------------+
             |
IKEv2 (UDP 500/4500)
             |
             v
+--------------------------+
|      China Server        |
|  (bj.01.me)              |
|--------------------------|
|   Xray:                  |
|   In: dokodemo-door      |
|   Out: VLESS+WS+TLS      |
+--------------------------+
             |
VLESS over WS+TLS (TCP 443)
             |
             v
+--------------------------+
|     Hong Kong Server     |
|     (hk.01.me)           |
|--------------------------|
|   Nginx: TLS Termination |
|   Xray:                  |
|   In: VLESS/WS           |
|   Out: freedom (UDP)     |
+--------------------------+
             |
Raw IKEv2 (UDP 500/4500)
             |
             v
+--------------------------+
|        US Server         |
|   (us-west.01.me)        |
|--------------------------|
|   strongSwan:            |
|   IKEv2 VPN Server       |
+--------------------------+
             |
             v
      <-- Internet -->

Technical Selection Logic

Why Three Hops?
- Solving Stability Issues: Directly connecting from China to a US server crosses the congested and unstable international public internet, resulting in high latency and frequent packet loss. We split this unstable long-distance link into two high-quality links:
  - China -> Hong Kong: Utilizing optimized routes from domestic cloud service providers (like Alibaba Cloud, Tencent Cloud) to Hong Kong, this link is usually at a dedicated line level, with low latency and extreme stability.
  - Hong Kong -> USA: Hong Kong, as Asia’s top network hub, has ample international export bandwidth and high-quality submarine cables to the US West Coast.
- Avoiding Geographical Detection: The final exit is in the USA, perfectly solving the IP geographical location restriction.
Why Use IKEv2?
- Client-Free, Cross-Platform: This is IKEv2’s biggest advantage. macOS, Windows, iOS, and Android systems all natively support it, requiring no third-party software installation, making configuration simple and extremely user-friendly for non-technical users.
- Standardization and Easy Management: Using standard username/password authentication makes adding, deleting, and managing users very convenient, far simpler than managing key files.
Technical Details of Each Hop (Why Set Up This Way)?
- Your Device -> Domestic Server: Your device uses the system’s built-in IKEv2 client to send standard UDP traffic to the domestic server’s 500 and 4500 ports.
- Domestic Server -> Hong Kong Server: This is the key to achieving “traffic encapsulation.”
  - Xray (dokodemo-door) receives the original IKEv2 UDP packets.
  - Xray (VLESS+WS+TLS) encapsulates these UDP packets into the VLESS protocol, transmits them via WebSocket, and finally encrypts them with TLS. Thus, all traffic sent from the domestic server will be encapsulated as standard HTTPS traffic (TCP 443 port) accessing the Hong Kong server’s domain.
- Hong Kong Server: This is a “relay and unpacking” intermediary.
  - Nginx acts as the entry point, handling encrypted HTTPS traffic, performing TLS decryption, and then reverse proxying the traffic to the backend Xray service.
  - Xray receives the VLESS over WebSocket data stream, unpacks it, restores it to the original IKEv2 UDP packets, and then forwards it directly to the US server via the freedom protocol.
- US Server: As the tunnel’s endpoint, the configuration is extremely clean.
  - strongSwan only needs to handle the clean, unencrypted IKEv2 UDP packets forwarded by the Hong Kong server, completing the final VPN authentication and data forwarding, allowing your traffic to flow from a US IP to the internet.

Through this series of ingenious designs, we trade some additional forwarding latency for higher connection stability while enjoying the convenience of a client-free setup.

Preparation

1. Server Requirements

Domestic Server (referred to as bj.01.me in this article)
Hong Kong Server (referred to as hk.01.me in this article)
US Server (referred to as us-west.01.me in this article)

2. Firewall Configuration

US Server:

Allow UDP 500/4500 port access from the Hong Kong Server IP

Hong Kong Server:

Allow TCP 443 port access from the Domestic Server IP

Domestic Server:

Allow UDP 500/4500 port access from your local network (if the local network IP is not fixed, you need to allow all UDP 500/4500 port access, but this poses a risk of DoS attacks)

3. Domain Names

Prepare domain names for the Hong Kong and US servers and set up correct DNS resolution. We will use these domain names to apply for TLS certificates later:

hk.01.me → Hong Kong Server IP
us-west.01.me → US Server IP

4. Generate UUID

Generate a UUID for the VLESS connection from China to Hong Kong:

1 2	export UUID_BJ_HK=$(uuidgen) echo "VLESS UUID from Beijing to Hong Kong: ${UUID_BJ_HK}"

Step One: Configure the US Endpoint Server

1.1 Install strongSwan

# 适用于 Debian/Ubuntu
sudo apt update
sudo apt install -y strongswan strongswan-pki libstrongswan-extra-plugins

# 开启 BBR 和 IP 转发
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
EOF
sudo sysctl -p

1.2 Apply for an SSL Certificate

Why is an SSL Certificate Needed?

In the IKEv2 VPN configuration, we use a domain name (us-west.01.me) as the server’s identity (leftid). To prevent man-in-the-middle attacks, the client must verify the server’s identity when connecting. An SSL certificate is the server’s “digital ID card” presented to the client, proving it is indeed us-west.01.me. The client will verify the certificate’s legitimacy through its built-in trusted root certificate authority (CA) list. Without a legitimate and valid certificate, the client will refuse to connect.

# 安装 certbot
sudo apt install -y certbot

# 申请证书（确保域名已解析到此服务器）
sudo certbot certonly --standalone -d us-west.01.me --non-interactive --agree-tos -m YOUR_EMAIL@example.com

# 重要：必须复制证书到 strongSwan 目录（这一步很容易被遗漏！）
sudo cp /etc/letsencrypt/live/us-west.01.me/fullchain.pem /etc/ipsec.d/certs/us-west-cert.pem
sudo cp /etc/letsencrypt/live/us-west.01.me/privkey.pem /etc/ipsec.d/private/us-west-key.pem
sudo chmod 600 /etc/ipsec.d/private/us-west-key.pem

Note: Please replace YOUR_EMAIL@example.com with your email to receive certificate expiration reminders.

About Certificate Renewal
Let’s Encrypt certificates are valid for 90 days and must be renewed regularly. The certbot package usually automatically configures a system scheduled task (cron job or systemd timer) to achieve automatic renewal upon installation.

You can test the automatic renewal process with the sudo certbot renew --dry-run command.

Important Tip: strongSwan will not automatically reload the certificate after it is updated. You need to configure a certbot renewal hook to automatically restart the service after the certificate is successfully updated. You can create a script in the /etc/letsencrypt/renewal-hooks/deploy/ directory, such as strongswan-reload.sh:

#!/bin/sh
# This script is run by certbot after a successful renewal

# Reload strongswan to apply the new certificate
systemctl reload strongswan

After creating the file, don’t forget to give it execution permissions: sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/strongswan-reload.sh.

1.3 Configure strongSwan

Why Force NAT-T Mode (forceencaps=yes)?

Standard IKEv2/IPsec VPN uses ESP (Encapsulating Security Payload) protocol to transmit encrypted data. ESP is an independent IP protocol (protocol number 50), neither TCP nor UDP. In our three-hop architecture, the intermediate Xray tunnel is designed to forward TCP or UDP traffic, and it cannot directly forward ESP, this special IP protocol.

To solve this problem, we utilize IKEv2’s NAT Traversal (NAT-T) feature. When NAT-T is enabled, all ESP packets are encapsulated in UDP packets (usually port 4500) for transmission. This way, the entire VPN data stream becomes standard UDP traffic.

In strongSwan configuration, the forceencaps=yes parameter is used to force NAT-T. Regardless of whether there is a NAT device between the client and server, it forces all traffic to use UDP encapsulation, perfectly compatible with our Xray-based UDP forwarding tunnel.

What are the purposes of UDP ports 500 and 4500?

UDP 500: This is the dedicated port for the IKE (Internet Key Exchange) protocol. It is responsible for the first phase of the VPN connection, which is the establishment of a security association. During this phase, the client and server authenticate each other, negotiate encryption algorithms, and generate keys for subsequent data transmission. This process is also known as the “control plane.”

UDP 4500: IKEv2 uses this port to transmit ESP data encapsulated with NAT-T. In other words, all actual user data (such as web browsing, file downloads, etc.) is transmitted through this port. This process can be seen as the “data plane.”

About Encryption Algorithm Compatibility

Different clients (Windows, macOS, iOS, Android, and different versions) support different sets of encryption algorithms. To ensure maximum compatibility, we have configured multiple combinations of algorithms from strong to weak:

Strong Encryption: aes256-sha256-ecp256 (preferred by modern clients)

Medium Encryption: aes128-sha256-modp2048 (supported by most clients)

Compatibility Encryption: 3des-sha1-modp1024 (required by older Windows clients)

The client will automatically select the strongest algorithm supported by both parties.

Create /etc/ipsec.conf:

sudo tee /etc/ipsec.conf > /dev/null << 'EOF'
config setup
    charondebug="all"
    uniqueids=yes
    strictcrlpolicy=no

conn %default
    keyexchange=ikev2
    ike=aes256-sha256-ecp256,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp2048,aes128-sha1-modp1024,3des-sha1-modp1024
    esp=aes256-sha256,aes128-sha256,aes128-sha1
    dpdaction=clear
    dpddelay=300s
    rekey=no
    forceencaps=yes
    fragmentation=yes
    mobike=yes

conn ikev2-vpn
    auto=add
    type=tunnel
    left=%any
    leftauth=pubkey
    leftcert=us-west-cert.pem
    leftid=us-west.01.me
    leftsubnet=0.0.0.0/0
    leftfirewall=yes
    rightauth=eap-mschapv2
    rightid=%any
    rightsourceip=10.42.42.0/24
    rightdns=8.8.8.8,8.8.4.4
    installpolicy=yes
EOF

Create /etc/ipsec.secrets:

Note on Key Type: Certbot generates ECDSA type keys (Elliptic Curve Cryptography) by default, not traditional RSA keys. You must specify the correct key type during configuration, or strongSwan will not be able to load the private key.

sudo tee /etc/ipsec.secrets > /dev/null << 'EOF'
# SSL 证书私钥（注意：行首的冒号代表本机）
: ECDSA us-west-key.pem

# 用户账号（用户名:密码）
user1 : EAP "password123"
user2 : EAP "password456"
EOF

1.4 Configure Firewall and NAT

# 配置 iptables NAT 规则（请根据实际网卡名称修改 eth0）
sudo iptables -t nat -A POSTROUTING -s 10.42.42.0/24 -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -s 10.42.42.0/24 -j ACCEPT
sudo iptables -A FORWARD -d 10.42.42.0/24 -j ACCEPT

# 保存规则
sudo apt install -y iptables-persistent
sudo netfilter-persistent save

1.5 Start the Service

1 2	sudo systemctl enable --now strongswan sudo systemctl status strongswan

Step Two: Configure the Hong Kong Relay Server

2.1 Install Software

sudo apt update
sudo apt install -y xray nginx certbot python3-certbot-nginx

# 开启 BBR
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sudo sysctl -p

2.2 Apply for SSL Certificate

Why is an SSL Certificate Needed?

On the Hong Kong server, the SSL certificate is used differently than on the US server. It is not used for IKEv2 authentication but for the Nginx service. Our design encapsulates the VLESS tunnel traffic from the domestic server in a standard TLS (HTTPS) connection.

# 申请证书
# 我们使用 certonly --standalone 模式，因为我们将手动配置 Nginx。
# --standalone 会临时启动一个 Web 服务器来验证域名，请确保 80 端口未被占用（可以暂时 `sudo systemctl stop nginx`）。
sudo certbot certonly --standalone -d hk.01.me --non-interactive --agree-tos -m YOUR_EMAIL@example.com

Note: Please replace YOUR_EMAIL@example.com with your email to receive certificate expiration reminders.

About Certificate Renewal
certbot will automatically configure renewal tasks. Since we used the standalone mode, Nginx will not automatically reload after certificate renewal. You need to configure a certbot renewal hook to automatically reload Nginx after the certificate is successfully updated. You can create a script in /etc/letsencrypt/renewal-hooks/deploy/nginx-reload.sh:

#!/bin/sh
# This script is run by certbot after a successful renewal

# Reload Nginx to apply the new certificate
systemctl reload nginx

After creating the file, don’t forget to give it execute permissions: sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/nginx-reload.sh.

2.3 Configure Nginx

Create /etc/nginx/sites-available/hk.01.me:

sudo tee /etc/nginx/sites-available/hk.01.me > /dev/null << 'EOF'
server {
    listen 80;
    server_name hk.01.me;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name hk.01.me;
    
    # SSL configuration
    ssl_certificate /etc/letsencrypt/live/hk.01.me/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hk.01.me/privkey.pem;
    
    # WebSocket proxy for IKEv2 UDP 500
    location /ws500 {
        proxy_pass http://127.0.0.1:10500;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }

    # WebSocket proxy for IKEv2 UDP 4500
    location /ws4500 {
        proxy_pass http://127.0.0.1:14500;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
     
    # Default location for other requests
    location / {
        return 404;
    }
}
EOF

# 启用站点
sudo ln -s /etc/nginx/sites-available/hk.01.me /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

2.4 Configure Xray

Create /usr/local/etc/xray/config.json:

# 使用之前生成的 UUID
sudo tee /usr/local/etc/xray/config.json > /dev/null << EOF
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "ipsec-in-500",
      "port": 10500,
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "${UUID_BJ_HK}",
            "encryption": "none"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/ws500"
        }
      }
    },
    {
      "tag": "ipsec-in-4500",
      "port": 14500,
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "${UUID_BJ_HK}",
            "encryption": "none"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/ws4500"
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "ipsec-out-500",
      "protocol": "freedom",
      "settings": {
        "redirect": "<美国服务器IP>:500"
      }
    },
    {
      "tag": "ipsec-out-4500",
      "protocol": "freedom",
      "settings": {
        "redirect": "<美国服务器IP>:4500"
      }
    }
  ],
  "routing": {
    "strategy": "rules",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["ipsec-in-500"],
        "outboundTag": "ipsec-out-500"
      },
      {
        "type": "field",
        "inboundTag": ["ipsec-in-4500"],
        "outboundTag": "ipsec-out-4500"
      }
    ]
  }
}
EOF

Note: Replace <US Server IP> with the actual US server IP address.

2.5 Start the Service

1 2	sudo systemctl enable --now xray sudo systemctl status xray

Step Three: Configure the Domestic Entry Server

3.1 Install Software

sudo apt update
sudo apt install -y xray

# 开启 BBR
sudo tee -a /etc/sysctl.conf > /dev/null << EOF
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sudo sysctl -p

3.2 Configure Xray

Create /usr/local/etc/xray/config.json:

sudo tee /usr/local/etc/xray/config.json > /dev/null << EOF
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 500,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "port": 500,
        "network": "udp"
      },
      "tag": "ipsec-in-500"
    },
    {
      "listen": "0.0.0.0",
      "port": 4500,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1",
        "port": 4500,
        "network": "udp"
      },
      "tag": "ipsec-in-4500"
    }
  ],
  "outbounds": [
    {
      "tag": "ipsec-out-500",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "hk.01.me",
            "port": 443,
            "users": [
              {
                "id": "${UUID_BJ_HK}",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/ws500"
        }
      }
    },
    {
      "tag": "ipsec-out-4500",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "hk.01.me",
            "port": 443,
            "users": [
              {
                "id": "${UUID_BJ_HK}",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/ws4500"
        }
      }
    }
  ],
  "routing": {
    "strategy": "rules",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["ipsec-in-500"],
        "outboundTag": "ipsec-out-500"
      },
      {
        "type": "field",
        "inboundTag": ["ipsec-in-4500"],
        "outboundTag": "ipsec-out-4500"
      }
    ]
  }
}
EOF

3.3 Start the Service

1 2	sudo systemctl enable --now xray sudo systemctl status xray

Step Four: Client Configuration

4.1 macOS Configuration

Open System Preferences → Network
Click the + button at the bottom left, select VPN
Choose IKEv2 as the VPN type
Fill in the configuration information:
- Server Address: bj.01.me
- Remote ID: us-west.01.me
- Local ID: Leave blank
- Authentication Settings: Choose Username
- Username: user1
- Password: password123

4.2 Windows Configuration

Open Settings → Network & Internet → VPN
Click Add a VPN connection
Fill in the configuration information:
- VPN Provider: Windows (built-in)
- Connection Name: IKEv2 VPN
- Server Name or Address: bj.01.me
- VPN Type: IKEv2
- Type of Sign-in Info: Username and password
- Username: user1
- Password: password123

4.3 iOS Configuration

Open Settings → General → VPN & Device Management → VPN
Click Add VPN Configuration
Choose IKEv2
Fill in the configuration information:
- Description: IKEv2 VPN
- Server: bj.01.me
- Remote ID: us-west.01.me
- Local ID: Leave blank
- User Authentication: Choose Username
- Username: user1
- Password: password123

4.4 Android Configuration

Open Settings → Network & Internet → VPN
Click + to add a VPN configuration
Choose IKEv2/IPSec MSCHAPv2 as the type
Fill in the configuration information:
- Name: IKEv2 VPN
- Server Address: bj.01.me
- IPSec Identifier: us-west.01.me
- Username: user1
- Password: password123
- CA Certificate: Choose (Unspecified)
Click Save

Note: We are using Let’s Encrypt certificates, whose root certificates are usually built into modern Android systems, so you can choose “Unspecified” for the CA certificate. If the connection fails, try accessing https://us-west.01.me in your mobile browser, which usually triggers the system to install the necessary intermediate certificates.

4.5 Linux Configuration

Linux systems can configure IKEv2 VPN connections in various ways, depending on the distribution and desktop environment you are using.

Method One: Using NetworkManager

Applicable to: Most Linux Desktops

Install Necessary Packages

1
2
3

# Ubuntu/Debian
sudo apt update
sudo apt install -y network-manager-strongswan strongswan-charon strongswan-libcharon

Restart NetworkManager
1
sudo systemctl restart NetworkManager
GUI Configuration
- Open Settings → Network or Network Connections
- Click the + button next to VPN
- Choose IPsec/IKEv2 (strongswan)
- Fill in the configuration information:
  - Name: IKEv2 VPN
  - Gateway: bj.01.me
  - Certificate: Choose Request from server
  - Method: Choose EAP
  - Username: user1
  - Password: password123
  - Virtual IP: Check Request internal IP
- Click Advanced for detailed configuration:
  - Server Identity: us-west.01.me
  - Check Force UDP encapsulation

Method Two: Configure using strongSwan Command Line

Applicable to: Linux systems without a GUI, such as Raspberry Pi

Install strongSwan

1
2
3

# Ubuntu/Debian
sudo apt update
sudo apt install -y strongswan strongswan-pki libstrongswan-extra-plugins

Configure strongSwan

Create /etc/ipsec.conf:

sudo tee /etc/ipsec.conf > /dev/null << 'EOF'
config setup
    charondebug="all"
    uniqueids=yes

conn ikev2-vpn
    auto=start
    keyexchange=ikev2
    type=tunnel
    left=%defaultroute
    leftauth=eap-mschapv2
    leftid=user1
    leftsourceip=%config
    right=bj.01.me
    rightauth=pubkey
    rightid=us-west.01.me
    rightsubnet=0.0.0.0/0
    ike=aes256-sha256-ecp256,aes256-sha256-modp2048
    esp=aes256-sha256
    forceencaps=yes
    dpdaction=restart
    dpddelay=30s
EOF

Configure Authentication Information

Create /etc/ipsec.secrets:

1
2
3

sudo tee /etc/ipsec.secrets > /dev/null << 'EOF'
user1 : EAP "password123"
EOF

Start the Connection

1 2	sudo systemctl enable --now strongswan sudo ipsec up ikev2-vpn

Verify the Connection
1
sudo ipsec statusall

User Management

Add New User

Edit /etc/ipsec.secrets on the US server:

sudo nano /etc/ipsec.secrets

# 添加新用户
newuser : EAP "newpassword"

Restart the strongSwan service:

1	sudo systemctl restart strongswan

Delete User

Remove the corresponding line from /etc/ipsec.secrets and then restart the service.

Verification and Testing

After a successful connection, verify using:

# 检查 IP 地址
curl ifconfig.me

# 检查 DNS 解析
nslookup google.com

# 测试连通性
ping 8.8.8.8

Check the connection status on the US server:

1	sudo ipsec statusall

Summary

Through the Mainland China -> Hong Kong -> USA IKEv2 VPN three-hop architecture, we have successfully built a client-free, cross-platform, and easy-to-manage three-layer tunnel solution. Compared to other three-layer tunnel solutions, IKEv2 has the following advantages:

No Client Installation Required: Natively supported by all major operating systems
Simple User Management: Supports username and password authentication, easy to add/delete users
One Account for Multiple Devices: A user can connect multiple devices simultaneously
Stable and Reliable: Based on the mature IPsec protocol, ensuring stable connections

In practical use, this architecture not only solves access issues for tools like Cursor but also provides a unified network access solution for the team. Through reasonable user management and server deployment, it can meet network needs in different scenarios.

Setting Up an IKEv2 Tunnel Without Installing a Client to Bypass Cursor's Regional Restrictions

Architecture Design

Technical Selection Logic

Preparation

1. Server Requirements

2. Firewall Configuration

3. Domain Names

4. Generate UUID

Step One: Configure the US Endpoint Server

1.1 Install strongSwan

1.2 Apply for an SSL Certificate

1.3 Configure strongSwan

1.4 Configure Firewall and NAT

1.5 Start the Service

Step Two: Configure the Hong Kong Relay Server

2.1 Install Software

2.2 Apply for SSL Certificate

2.3 Configure Nginx

2.4 Configure Xray

2.5 Start the Service

Step Three: Configure the Domestic Entry Server

3.1 Install Software

3.2 Configure Xray

3.3 Start the Service

Step Four: Client Configuration

4.1 macOS Configuration

4.2 Windows Configuration

4.3 iOS Configuration

4.4 Android Configuration

4.5 Linux Configuration

Method One: Using NetworkManager

Method Two: Configure using strongSwan Command Line

User Management

Add New User

Delete User

Verification and Testing

Summary

Comments