Google Cloud：OpenVPN虚拟机及客户端通过IPSec隧道通信配置咨询

Hey there, let’s walk through this setup step by step—I’ve tackled similar configurations before, so let’s start with the core idea first: we need to make sure OpenVPN clients can route traffic through the OpenVPN VM into the IPSec tunnel, and also ensure the VM itself can use the tunnel properly.

1. First, Verify the IPSec Tunnel Works for the VM #

Before worrying about OpenVPN clients, confirm the OpenVPN VM can already reach the IPSec peer’s subnet.

• Ping a test IP on the remote IPSec subnet from the VM—if that fails, fix the IPSec tunnel first (check your IPSec config’s subnet settings, route tables, or firewall rules).
• Check the VM’s route table with ip route show (Linux) or route print (Windows) to ensure there’s an entry pointing the remote subnet to the IPSec tunnel interface (usually something like tun0 or ipsec0).
• If the route’s missing, add it manually: ip route add <remote-subnet>/<mask> dev <ipsec-interface> (Linux). For permanent routes, add this to your system’s route config (like /etc/network/interfaces or using nmcli for NetworkManager).

2. Push Remote IPSec Subnet Routes to OpenVPN Clients #

By default, OpenVPN clients only get routes to the OpenVPN server’s local subnet. We need to tell them to send traffic for the IPSec remote subnet through the VPN.

• Edit your OpenVPN server config (typically /etc/openvpn/server.conf on Linux):
  Add a line like: push "route <remote-subnet> <subnet-mask>"
  Example: If the IPSec remote subnet is 192.168.200.0/24, use push "route 192.168.200.0 255.255.255.0"
• Restart the OpenVPN server service: systemctl restart openvpn@server (for systemd-based systems)

3. Enable IP Forwarding on the OpenVPN VM #

The VM needs to act as a router between the OpenVPN client subnet and the IPSec tunnel.

• Temporary enable: Run echo 1 > /proc/sys/net/ipv4/ip_forward (Linux)
• Make it permanent: Edit /etc/sysctl.conf, uncomment or add net.ipv4.ip_forward=1, then run sysctl -p to apply changes.

4. Configure Firewall Rules to Allow Traffic Forwarding #

Your VM’s firewall (iptables, ufw, firewalld) needs to let traffic pass between the OpenVPN client subnet and the IPSec remote subnet.

For iptables: #

# Allow traffic from OpenVPN clients to IPSec remote subnet
iptables -A FORWARD -s <openvpn-client-subnet>/<mask> -d <remote-subnet>/<mask> -j ACCEPT
# Allow reverse traffic from IPSec subnet back to OpenVPN clients
iptables -A FORWARD -s <remote-subnet>/<mask> -d <openvpn-client-subnet>/<mask> -j ACCEPT

Note: Don’t apply SNAT to IPSec traffic—this will break the tunnel’s ESP/AH packets since IPSec relies on original source IPs.

For ufw: #

• Edit /etc/ufw/sysctl.conf and set net.ipv4.ip_forward=1
• Add these lines to /etc/ufw/before.rules (before the *filter section):

  *nat
  :POSTROUTING ACCEPT [0:0]
  # No SNAT for IPSec traffic
  -A POSTROUTING -s <openvpn-client-subnet>/<mask> -d <remote-subnet>/<mask> -j ACCEPT
  COMMIT
  

• Then add forwarding rules in the *filter section:

  -A FORWARD -s <openvpn-client-subnet>/<mask> -d <remote-subnet>/<mask> -j ACCEPT
  -A FORWARD -s <remote-subnet>/<mask> -d <openvpn-client-subnet>/<mask> -j ACCEPT
  

• Restart ufw: systemctl restart ufw

5. Update IPSec Policy to Include OpenVPN Client Subnet #

Some IPSec implementations (like StrongSwan) use policy-based routing to control which traffic goes through the tunnel. You need to include the OpenVPN client subnet in these policies.

• Edit your IPSec config (e.g., /etc/ipsec.conf for StrongSwan):
  In the connection section, update leftsubnet to include both the VM’s local subnet and the OpenVPN client subnet:

  leftsubnet=<vm-local-subnet>/<mask>,<openvpn-client-subnet>/<mask>
  

• Restart the IPSec service: systemctl restart strongswan
• Verify the policy with ip xfrm policy—you should see entries allowing traffic between the OpenVPN client subnet and the remote IPSec subnet.

6. Test from the OpenVPN Client #

Once all configs are set, test from a client:

• Connect to the OpenVPN server, then check the route table to confirm the remote IPSec subnet route exists.
• Ping a device on the remote IPSec subnet—if it works, you’re good to go!
• If not:
  1. Check if the OpenVPN server can ping the remote IP first.
  2. Verify IP forwarding is enabled on the VM.
  3. Check firewall rules on both the VM and the client.
  4. Use tcpdump on the VM to see if client traffic reaches the IPSec interface: tcpdump -i <ipsec-interface> host <remote-test-ip>

• Route Conflicts: If your OpenVPN client subnet overlaps with the IPSec remote subnet, routing will break. Adjust the OpenVPN server’s client subnet (edit the server line in server.conf, e.g., server 10.9.0.0 255.255.255.0).
• IPSec Tunnel Misconfiguration: Double-check that your IPSec tunnel is set up for site-to-site traffic, not just client-to-site.
• Firewall Blocking ESP/AH Packets: Ensure the VM’s firewall allows IPSec protocol traffic (ESP: protocol 50, AH: protocol 51) and UDP port 500/4500 for IKE.

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