IPSec Project

IPsec at Scale: Hub-and-Spoke Design for NATed Sites
Holden Weber, Rene Ruhigita, Connor Horning

The Problem

We wanted to connect all our networks, Site Kivu, Site Cleveland, and Site Washington, together to run bigger, wide-scale projects across multiple WAN connections and sites. The goal wasn’t primarily security; it was about achieving high availability, clustering, and being able to manage and test multiple labs as if they were part of a single, unified network. To address the challenges of NAT, dynamic public IP addresses, and SOHO router limitations, we opted for a hub-and-spoke topology. This allowed all remote sites to initiate connections to a central hub with a public IP, simplifying routing, scaling to multiple sites, and keeping the network manageable.

What we used (Pfsense, Opnsense, StrongSwan) and why?

OPNsense (Two Sites)

Two of the three sites ran OPNsense, mainly because that’s what those labs were already using. It provided the necessary IPsec, routing, and firewall features needed for the design without requiring anything unusual or custom.

pfSense (One Site)

One site intentionally ran pfSense. This wasn’t because it was better or worse; it was to prove the design wasn’t platform-dependent. If the topology worked with both pfSense and OPNsense, then the architecture itself was solid.

StrongSwan (Hub)

The StrongSwan system did not behave like the other sites. Instead, it acted as the central hub to which all remote networks connected. It ran on a VPS with a stable public IP, which served as the fixed anchor point for every IPsec tunnel in the environment.

Each pfSense and OPNsense site initiated an outbound IPsec tunnel to the StrongSwan hub. This design allowed all remote sites to connect successfully, even though they were behind NAT and using dynamic public IP addresses, without requiring port forwarding or special ISP configuration.

Running StrongSwan at the hub gave us full control over IKEv2 and, more importantly, inter-tunnel routing. Unlike typical firewall-to-firewall VPNs that terminate traffic at the tunnel endpoint, the StrongSwan hub could receive traffic from one site and forward it to another. This capability is what transformed multiple independent site-to-site VPNs into a single, routed multi-site network.

Because the hub had a fixed public IP and handled all routing between tunnels, the architecture scaled cleanly while remaining reliable and predictable, even as spoke sites changed public addresses.

More Details on what these are

PfSense

An open-source firewall and routing platform based on FreeBSD that provides firewalling, routing, NAT, and VPN services.

OPNsense

An open-source FreeBSD-based firewall platform offering routing, firewalling, and VPN functionality through a web interface.

StrongSwan

An open-source IPsec implementation for Linux that handles IKE key exchange and IPsec tunnel management.

Overview of the Hub-and-Spoke Topology

We went with a hub-and-spoke design where every remote site connects to a single central hub. In our case, that hub is a VPS with a public IP running StrongSwan. Each site brings up an IPsec tunnel from its WAN interface to the hub over the Internet.

Because the tunnel is always initiated by the remote site, this works even if the site is behind a NAT or a basic SOHO router. No inbound port forwarding is required, which was a hard limitation for some of our setups.

When the tunnel comes up, IKE Phase 1 handles authentication and key exchange using a pre-shared key. Once that’s done, IKE Phase 2 is where we define what actually goes through the tunnel. This is where we specify which local networks should be reachable and which remote networks they’re allowed to talk to.

Only traffic that matches those networks is encrypted and sent through the tunnel to the hub. Everything else follows the normal default route out to the internet. From there, the hub routes traffic between sites as needed, effectively tying multiple independent labs together without breaking normal WAN access.

This setup lets us treat separate networks like one larger environment while working around NAT, changing public IPs, and the limitations of consumer networking gear.

Image

Pros & Cons

Pros

Cons

Technical implementation

The Hub: Ubuntu VPS with StrongSwan

The core of the network is an Ubuntu VPS running StrongSwan. It allows each home lab to communicate not only with the VPS but also with every other homelab in the mesh.

The key to making this work without complex routing protocols was the traffic selector config in ipsec.conf. By defining a list of subnets in the “leftsubnet” parameter, we instructed the VPS to encrypt traffic destined for any participating lab, not just the VPS itself.

Configuration of VPS Servers (Ubuntu 22.04.5 LTS [Jammy Jellyfish]).

Step 1: Install strongSwan

# Update package lists
sudo apt update
# Install strongSwan
sudo apt install strongswan strongswan-pki libcharon-extra-plugins -y
# Verify installation
ipsec --version

Step 2: Generate Pre-Shared Key

# Generate a strong PSK
openssl rand -base64 32

Save this PSK securely - you'll need it for both Ubuntu and OPNsense.

Example output: cxgchVjKbCfj38tiv+4FX3X8a9MmJI1UUJO7a+f7...

Step 3: Configure IPsec Connection

Edit /etc/ipsec.conf:

sudo nano /etc/ipsec.conf

Add this configuration:

config setup
    uniqueids=never
    charondebug="ike 2, knl 2, cfg 2, net 2, esp 2"

conn OpnSenseRene
    left=Public ip of Hub
    leftid=Public ip of Hub
    leftsubnet=Other Spoke Subnets (Example : 10.0.3.0/24,172.16.1.0/24)
    right=Public ip of Spoke (Doesn’t matter if not static because of MOBIKE)
    rightid=%any
    rightsubnet=Your Spoke Subnet
    mark=1002
    auto=start
    keyexchange=ikev2
    ike=aes256-sha256-modp2048
    esp=aes256-sha256-modp2048
    dpdaction=restart
    dpddelay=30s
    dpdtimeout=120s
    authby=psk
    ikelifetime=24h
    keylife=1h

Configuration Explanation:

Step 4: Configure Pre-Shared Key

Edit /etc/ipsec.secrets:

sudo nano /etc/ipsec.secrets

Add this line (replace with your actual PSK):

67.217.242.202 146.135.14.64 : PSK "YOUR_GENERATED_PSK_HERE"

Security: Ensure proper file permissions:

sudo chmod 600 /etc/ipsec.secrets
sudo chown root:root /etc/ipsec.secrets

Useful Commands Reference

The spokes: OPNsense and pfSense

On the client side, we either set up pfSense or OPNsense. We avoided the complexity of BGP or OSPF by utilizing multiple phase 2 entries. A single IPsec Phase 1 connection to the hub carries multiple “Child SAs”, one for each destination in the network.

IPsec Configuration in OPNsense:

Configuring Phase 1 (Connection)

Configuring Local and Remote Authentication:

Children Configuration:

Check the Status

Conclusion

By using a hub-and-spoke IPsec architecture with a publicly reachable StrongSwan hub, we were able to connect multiple NATed, dynamically addressed sites into a single routed network. This design avoided the common limitations of consumer ISPs and SOHO routers while still providing reliable inter-site connectivity and centralized control.

The combination of pfSense, OPNsense, and StrongSwan demonstrated that the solution was platform-agnostic and rooted in sound network design rather than vendor-specific features. Centralizing routing at the hub allowed us to scale to additional sites without the complexity of full mesh VPNs or dynamic routing protocols, making the environment easier to manage and troubleshoot.

While the hub introduces tradeoffs such as a single point of failure and potential throughput constraints, these limitations are well understood and can be mitigated through redundancy and resource scaling. Overall, this approach provided a practical, scalable solution for linking multiple home labs and remote networks, enabling larger distributed projects to function as if they were part of one cohesive environment.