Cloud connectivity from OPNsense — IPsec and WireGuard to AWS, Azure and GCP

Cloud connectivity is the site-to-site VPN problem extended to a network that is not the operator’s. AWS, Azure, GCP, and other cloud providers expose managed VPN endpoints that terminate IPsec tunnels; OPNsense terminates the other end. The protocols are the same as on-premise site-to-site; the addressing is different; the routing is different; the operational model is different. The cloud side has its own routing tables, its own high-availability patterns, and its own failure modes. The operator who treats the cloud as another site in the fabric can apply the lessons learned on-premise; the operator who treats it as a black box will be surprised.

This lesson covers the patterns for cloud connectivity — IPsec with the managed VPN services, WireGuard as a software alternative, the addressing and routing on the cloud side, the high-availability patterns, and the failure modes.

The two patterns

The cloud provider’s VPN endpoint is one of two patterns:

• IPsec with the managed VPN service. AWS Site-to-Site VPN, Azure VPN Gateway, GCP Cloud VPN. The cloud provider runs the endpoint; the operator runs the OPNsense end. The protocol is IKEv2 IPsec. The configuration on OPNsense matches the cloud provider’s requirements exactly — Phase 1 / Phase 2 proposals, PFS, lifetime, peer IP.
• WireGuard with a cloud-side WireGuard endpoint. Software-defined, runs on a cloud VM. The cloud provider does not have a managed WireGuard product. The operator runs a WireGuard instance on a cloud VM (or a container) and configures the OPNsense end with the cloud VM as the peer. Simpler than IPsec, less interoperable, more flexible.

The choice depends on what the operator wants from the cloud provider. The managed IPsec service is the right choice when the operator wants the cloud to manage the endpoint — uptime, scaling, patches are the cloud’s responsibility. WireGuard on a cloud VM is the right choice when the operator wants full control of the endpoint and is willing to manage a VM in the cloud.

AWS Site-to-Site VPN

AWS Site-to-Site VPN terminates IPsec tunnels on the AWS side and presents them as a virtual private gateway (VGW) or a transit gateway (TGW) attached to one or more VPCs. The OPNsense side configures two IPsec tunnels (one to each AWS endpoint), runs BGP over the tunnels (AWS requires BGP), and learns the VPC routes dynamically.

The OPNsense configuration:

• Phase 1. IKEv2, AES-256-GCM (or AES-256-SHA256 if GCM is not supported by the AWS endpoint version), DH group 14, lifetime 28800 seconds.
• Phase 2. ESP, AES-256-GCM, PFS group 14, lifetime 3600 seconds.
• BGP. AWS announces the VPC CIDR (e.g. 10.0.0.0/16); OPNsense announces the on-premise CIDRs (e.g. 10.1.0.0/16).

# AWS-style IPsec configuration on OPNsense (Phase 1 + Phase 2).
# AWS provides the exact proposals; the operator configures OPNsense to match.

# Phase 1
ike proposal:
  encryption: aes256gcm16-prf
  dh-group: 14
  lifetime: 28800

# Phase 2
esp proposal:
  encryption: aes256gcm16
  pfs-group: 14
  lifetime: 3600

The BGP session is over the IPsec tunnel; OPNsense’s FRR plugin runs bgpd and peers with the AWS endpoint. AWS provides the peer IP (a link-local address in the 169.254.0.0/16 range); OPNsense uses the tunnel’s local address as its BGP endpoint.

Azure VPN Gateway

Azure VPN Gateway is the managed IPsec endpoint. The gateway is configured with a “local network gateway” (the on-premise OPNsense firewall’s public IP) and one or more “connections” (the IPsec tunnels). The OPNsense side mirrors the configuration.

Azure supports both policy-based and route-based VPNs. The route-based VPN is the production choice; it uses IKEv2 and BGP. Azure provides the BGP peer IP; OPNsense announces the on-premise CIDRs.

The key Azure-specific settings:

• Gateway SKU. The SKU determines the bandwidth and tunnel count. VpnGw3 is the production SKU; lower SKUs are limited.
• Active-active mode. Azure supports active-active VPN gateways for redundancy. The OPNsense side configures two tunnels, one to each gateway instance.
• BGP. Azure requires (or strongly recommends) BGP for route-based VPNs.

GCP Cloud VPN

GCP Cloud VPN supports both classic VPN (single tunnel, policy-based or route-based) and HA VPN (two tunnels, route-based, BGP). HA VPN is the production choice.

The HA VPN configuration on OPNsense:

• Two IPsec tunnels, one to each GCP VPN endpoint interface.
• IKEv2, AES-256-GCM, PFS group 14.
• BGP over each tunnel; GCP announces the VPC CIDR.

GCP-specific notes:

• The GCP VPN endpoint interfaces have specific IP addresses; OPNsense configures one peer per interface.
• GCP requires BGP for HA VPN; static routes are not supported on HA VPN.
• GCP’s MTU for IPsec is 1460 bytes (similar to AWS).

WireGuard as a cloud alternative

When the operator wants full control of the cloud endpoint, a WireGuard instance on a cloud VM is the answer. The deployment:

1. Provision a small VM in the cloud. A VM with a public IP, in the same VPC as the resources that need to be reached. The VM’s subnet is a /28 or /29 (small but routable in the VPC).
2. Install WireGuard on the VM. A standard WireGuard setup with one peer pointing at OPNsense.
3. Configure routing on the cloud side. The VPC’s route table gets a route for the on-premise CIDR (10.1.0.0/16) pointing at the WireGuard VM’s private IP.
4. Configure OPNsense. Add a WireGuard peer pointing at the WireGuard VM’s public IP, with AllowedIPs covering the VPC CIDR.

The trade-off:

• Managed IPsec. Simpler on OPNsense (AWS/Azure/GCP provide the configuration), but the operator is locked into the cloud provider’s IPsec implementation and pricing.
• WireGuard on a cloud VM. Full control, simpler protocol, but the operator manages the VM (uptime, patches, scaling).

For a small number of VPCs and a small number of cloud projects, WireGuard on a VM is often simpler. For a large cloud presence with many VPCs and regions, the managed IPsec service with a transit gateway is more scalable.

High availability

The high-availability pattern for cloud VPN:

1. Two IPsec tunnels. Each tunnel goes to a different cloud endpoint (different availability zone, different gateway instance).
2. BGP multi-path. Both BGP sessions announce the same routes; OPNsense and the cloud side install both paths; traffic uses one or the other based on the routing policy.
3. Health monitoring. The firewall monitors the tunnel state and alerts on drops. BGP timers detect the drop; the operator is paged.
4. Failover testing. The discipline: simulate a tunnel drop (down one of the tunnels) and confirm that traffic continues via the second tunnel within the configured failover time.

# Verify both BGP sessions are up. vtysh -c runs one command and exits,
# which is what you want in a check script; plain `vtysh` opens the shell.
PEER_IP=169.254.10.1

vtysh -c 'show ip bgp summary'
vtysh -c "show ip bgp neighbors $PEER_IP"

MTU and MSS clamping

Cloud VPN endpoints typically have a lower MTU than the LAN MTU (1500 bytes). The operator must:

1. Set the IPsec tunnel MTU. On OPNsense, the IPsec interface MTU should match the cloud provider’s MTU (1437 for AWS, 1460 for Azure and GCP).
2. Configure MSS clamping. Firewall rules for traffic destined to the VPC should have MSS clamping set to MTU minus 40 (IP header + TCP header). For AWS, MSS = 1397; for Azure and GCP, MSS = 1420.
3. Test with large packets. ping -s 1400 from an on-premise host to a VPC host — must succeed without fragmentation.

Verification

After deploying cloud connectivity, verify:

1. From OPNsense, ping the cloud side’s BGP peer IP — must succeed over the IPsec tunnel.
2. From an on-premise host, traceroute to a VPC host — must traverse the IPsec tunnel.
3. From a VPC host, traceroute to an on-premise host — must traverse the IPsec tunnel in the reverse direction.
4. From OPNsense, vtysh show ip bgp summary — both BGP sessions (one per tunnel) must be up.
5. From the cloud console, the BGP session status must be “up” for both tunnels.

A configuration that passes 1-2 but fails 3-4 has one-direction routing. A configuration that passes 3-4 but fails 1 has tunnels up but no routing protocol. The operator checks every link.