IPSec Configuration

IPSec is an alternative tunnel protocol for edge peering that uses AES-256-GCM encryption. While WireGuard is the default and recommended protocol for most deployments, IPSec is available when compliance requirements mandate it or when integrating with networks that require industry-standard IPSec encryption.

When to Use IPSec

Choose IPSec over WireGuard when:

• Your organization's security policy requires AES-256-GCM encryption specifically.
• Compliance frameworks (e.g., PCI-DSS, HIPAA, FedRAMP) mandate IPSec.
• You need explicit control over rekeying intervals and Security Association lifecycle.
• You are integrating with third-party networks that only support IPSec.

For all other cases, WireGuard is recommended due to its lower overhead, faster handshakes, and simpler key management.

How IPSec Peering Works

When you create a peering group with the IPSec tunnel protocol, the system manages IPSec Security Associations (SAs) instead of WireGuard key pairs:

1. SA Key Generation -- When a link is created between two members, AES-256-GCM encryption keys (256-bit) are generated for each direction of traffic.
2. SPI Allocation -- Each direction of each link receives a unique Security Parameter Index (SPI) that identifies the SA.
3. Key Distribution -- SA keys are encrypted at rest in the database and distributed to edge devices via MQTT.
4. Tunnel Establishment -- Edge devices use the SA material to establish IPSec tunnels with their peers.

Each link has two directional SAs -- one for traffic from Edge A to Edge B, and one for traffic from Edge B to Edge A. This ensures that each direction uses independent encryption keys.

Encryption Details

Parameter	Value
Encryption Algorithm	AES-256-GCM (authenticated encryption)
Integrity Algorithm	None (GCM provides built-in authentication)
Key Size	256 bits (32 bytes)
GCM Salt	4-byte nonce prefix per SA direction
Encapsulation	UDP on the configured listen port

AES-256-GCM is an authenticated encryption mode that provides both confidentiality and integrity in a single operation, making a separate integrity algorithm unnecessary.

Rekeying

Rekeying generates new SA keys and SPIs for all links in a peering group. This maintains forward secrecy -- if a key is compromised, only traffic encrypted with that specific key is affected.

Rekey Interval

When creating an IPSec peering, you configure a Rekey Interval in hours (default: 24). This controls how frequently SA keys should be refreshed.

Interval	Use Case
1-4 hours	High-security environments requiring frequent key rotation
24 hours (default)	Standard deployments balancing security and stability
168 hours (1 week)	Low-change environments where stability is prioritized

Manual Rekeying

You can trigger an immediate rekey from the peering detail page:

1. Select the IPSec peering group from the list.
2. In the detail panel, click the Rekey IPSec button (amber button in the action bar).
3. New SA keys and SPIs are generated for all links.
4. Updated configurations are pushed to all member edges immediately.
5. A toast notification confirms how many links were rekeyed.

info

During a rekey, there is a brief period where edges transition to the new SA keys. Traffic may experience momentary disruption (typically under one second) as edges install the new SAs.

What Happens During a Rekey

1. New 256-bit AES keys and GCM salts are generated for every link direction.
2. New SPIs are allocated for each SA.
3. The new key material is encrypted and stored in the database.
4. All member edges are marked as needing configuration sync.
5. Updated configurations with new SA material are pushed to all edges via MQTT.
6. The last_rekey_at timestamp is updated on the peering group.

Status Indicators

IPSec peerings display status differently from WireGuard peerings:

Peering List

IPSec peering groups show an amber IPSec badge next to the peering name in the list view, making it easy to distinguish them from WireGuard peerings.

Member Status

Status	Meaning
SA Active	Security Associations are established and the member is passing traffic.
SA Pending	SAs are being negotiated or have not yet been established.

This differs from WireGuard peerings, which show the last handshake timestamp instead.

Link Status

Status	Meaning
SA: Established	The IPSec SA between the two edges is active and encrypting traffic.
SA: Down	The SA is not established. Traffic is not flowing on this link.

Firewall Requirements

IPSec peerings use UDP encapsulation on the configured listen port (default 51820). Ensure that:

• The listen port is open for inbound UDP traffic on all member edges.
• If dual tunnel is enabled, the secondary listen port is also open.
• NAT traversal is supported -- UDP encapsulation allows IPSec to work through NAT devices.

tip

Unlike traditional IPSec deployments that require ESP protocol (IP protocol 50) to be allowed, SecureLink IPSec peering uses UDP encapsulation, which works through NAT and standard firewalls without special rules beyond the listen port.

Dual Tunnel with IPSec

IPSec fully supports dual tunnel redundancy (Active-Standby and Active-Active). Each tunnel in a dual tunnel pair has its own independent set of SAs:

• Primary tunnel: Uses SA keys and SPIs from the primary link.
• Secondary tunnel: Uses separate SA keys and SPIs from the secondary link.

Rekeying refreshes the SA material for both tunnels simultaneously. BGP and BFD operate identically to WireGuard dual tunnel configurations.

Troubleshooting IPSec Peering

SA Pending After Creation

If a member shows SA Pending after being added to the group:

1. Verify the edge is online and sending heartbeats.
2. Check that the configuration was received -- look for MQTT delivery confirmation in edge logs.
3. Confirm the listen port is reachable from the peer edge.
4. Try syncing the peering configuration from the detail page.

SA Down After Working Previously

If an established SA goes down:

1. Check WAN connectivity on both edges involved in the link.
2. Verify no firewall changes have blocked the listen port.
3. Try a manual rekey -- this generates fresh SA material and pushes it to both edges.
4. Check edge logs for SA negotiation errors.

Rekey Failures

If the Rekey IPSec button produces an error:

1. Verify you have permission to manage the peering group.
2. Check that the peering group is an IPSec peering (rekey is only available for IPSec).
3. Ensure the API server is running and accessible.
4. Check server logs for detailed error information.