Setting up OpenVPN Connection between Two PCs behind a CGNAT Cloud Server

Establishing a direct OpenVPN tunnel between two devices behind Carrier-Grade NAT (CGNAT) requires routing all traffic through an intermediate server with a public IP. This hub-and-spoke architecture bypasses the inability of CGNAT to accept inbound connections by having both clients connect outbound to the central node, which then forwards packets between them.

The CGNAT Connectivity Challenge

Carrier-Grade NAT is a technique used by Internet Service Providers to conserve IPv4 addresses. It places multiple users behind a single public IP address, making it impossible for external devices or other peers on the same network to initiate a connection directly to your local machine. In a typical Peer-to-Peer (P2P) VPN scenario, each endpoint must be reachable via its own public IP or port-forwarded router. Since CGNAT providers do not offer port forwarding or unique IPs to residential customers, standard P2P configurations fail immediately. To solve this, you must adopt a Hub-and-Spoke topology. One machine acts as the "Hub" (the server) and possesses a static public IP address, often provided by a Virtual Private Server (VPS). The other two machines act as "Spokes" (clients). These clients initiate outgoing connections to the Hub. The Hub receives these connections and manages the traffic flow between the two clients. This approach does not require any changes to your ISP settings or router configuration because all traffic originates from inside your local network. For those interested in alternative protocols that handle NAT traversal more natively, exploring WireGuard Wizardry: Bypassing CGNAT and VPS can provide insights into modern tunneling techniques, though OpenVPN remains robust for complex routing needs.

Server Configuration and Network Setup

The foundation of this setup is the server. You need a machine with a public IP address running Linux or a compatible OS. Install OpenVPN and generate the necessary certificate authority (CA), server certificate, and key files. Ensure the server configuration file specifies the correct subnet for the virtual private network (VPN), such as 10.8.0.0/24. Crucially, you must enable IP forwarding on the server kernel to allow it to route packets between interfaces. Run the following command to enable IP forwarding temporarily:

sysctl -w net.ipv4.ip_forward=1

To make this persistent across reboots, add or modify the line net.ipv4.ip_forward=1 in your /etc/sysctl.conf file. Without this setting, the server will drop packets that are not destined for itself, breaking the bridge between the two clients. Once the server is running, configure the firewall to accept UDP traffic on the OpenVPN port (default 1194). More importantly, you must configure Network Address Translation (NAT) so that traffic originating from one client appears to come from the server when it reaches the other client. This ensures that return traffic is correctly routed back through the tunnel.

Configuring Client Machines

On each client machine, install the OpenVPN client software. Generate individual certificates for each client to maintain security separation. Create a configuration file for each client that points to the public IP address of your Hub server. Set the protocol to UDP and specify the same port used on the server. In the client configuration, ensure that the pull` directive is used if you want the server to push routing tables, or manually define routes to force traffic through the VPN tunnel. If you intend for the clients to communicate with each other over the VPN interface specifically, they do not need full internet access via the tunnel unless desired. However, for seamless connectivity, it is often easier to route all traffic through the Hub. Refer to Setting Up Local Machine as VPS: Using OpenVPN Configuration for detailed steps on generating client-specific keys and handling certificate revocation lists securely.

Enabling Client-to-Client Routing on the Server

This is the most critical step often missed in generic guides. By default, OpenVPN isolates clients from each other for security reasons. To allow Client A to talk to Client B, you must enable the client-to-client directive in the server configuration file. Add the following line to your server's .conf file:

client-to-client

After adding this directive, restart the OpenVPN service on the server. Next, verify that iptables rules are correctly set up to masquerade outgoing traffic. The standard rule usually looks like this:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Replace eth0 with your actual public-facing network interface name. This rule translates the source IP of packets coming from the VPN subnet to the server's public IP, allowing the return path to function correctly across the internet and back through the VPN tunnel to the destination client. If you encounter issues where the connection starts but data does not flow, check OpenVPN Can't Open (Kali) for troubleshooting common daemon errors and permission issues that might prevent the tunnel from establishing properly.

Testing and Verification

Connect both clients to the server. Verify that each client has received an IP address from the VPN subnet assigned by the server. Use ping commands to test connectivity between the two clients' VPN IPs. For example, from Client A, ping the VPN IP of Client B. If the ping succeeds, the routing is working. Check the server logs for any dropped packets or authentication failures. Ensure that no local firewalls on the client machines are blocking ICMP or UDP traffic on the VPN interface. Once verified, you can establish SSH sessions, file transfers, or other services between the two CGNAT-restricted machines via the secure tunnel.

Frequently Asked Questions

Can I use this setup without a public VPS?

No, at least one node must have a publicly routable IP address to accept incoming connections from both CGNAT clients. You cannot create a pure P2P link between two CGNAT devices without a relay server or STUN/TURN infrastructure.

Does this setup hide my real IP address from the other client?

Yes, the other client only sees the VPN-assigned IP address of the peer. However, the Hub server can see all traffic passing through it, so trust the server operator implicitly regarding privacy.

What happens if the server goes offline?

The connection between the two clients will break completely until the server comes back online. Unlike P2P setups, there is no fallback mechanism; the entire communication chain depends on the central hub being available.

Is OpenVPN slower than WireGuard for this use case?

OpenVPN typically has higher overhead due to TLS handshakes and encryption layers. WireGuard is generally faster and lighter, making it a better choice for low-latency applications, but OpenVPN offers more granular control over routing and legacy compatibility.

How do I restrict one client from accessing the internet through the other?

You can configure specific iptables rules on the server to block forwarding between the two VPN subnets while still allowing them to reach the internet. This requires advanced firewall knowledge to isolate internal traffic paths effectively.