TABLE OF CONTENTS

• Overview
• Default Cryptographic Settings
  • 2.1  Branch / Hub ↔ Controller Tunnels
  • 2.2  Branch / Hub ↔ Branch / Hub Tunnels
• Quick Reference Summary
• Algorithm Performance Guidance
• Changing Default IKE and IPsec parameters between Branch and Controllers
  • 5.1  Before Deploying Branches
  • 5.2  After Branches Are Already Deployed
• Changing Default IPsec parameters between Branch/Hub and Branch/Hub
• Diffie-Hellman Groups & Perfect Forward Secrecy

  • Group 19 (ECDH — NIST P-256)

• Frequently Asked Questions

  • Why does Versa use GCM for Branch-to-Branch but SHA-256 for Branch-to-Controller?
    

  • Is it safe to mix AES-128 and AES-256 devices in the same deployment?
  • What happens if IKE parameters mismatch after a cipher change?
  • AES-256-GCM vs AES-256 + SHA-256 — Which Should I Use?
  • AES-256-GCM vs AES-256 + SHA-384 — Which Is More Secure?
  • AES-256-GCM vs AES-256 + SHA-512 — Is SHA-512 Stronger?

Overview

Versa SD-WAN leverages industry-standard IKEv2 and IPsec protocols to secure all overlay tunnels between network elements. IKEv2 and IPsec are used to establish secure communication between Branch/Hub devices and Controllers, while data exchanged between Branch/Hub devices is encrypted using IPsec.

All traffic traversing the Versa SD-WAN overlay is encrypted within the IPsec tunnel, ensuring confidentiality and integrity across the WAN.

This article outlines the default cryptographic algorithms configured out of the box, explains recommended settings for different traffic paths, and provides performance considerations to help customers make informed decisions when customizing IKE and IPsec encryption, integrity algorithms, and DH/PFS groups.

Two distinct tunnel types are used in a Versa SD-WAN deployment, each with independently configurable cryptographic profiles:

• Branch / Hub → Controller  — control-plane and management traffic
• Branch / Hub → Branch / Hub  — data-plane overlay traffic (spoke-to-spoke and hub-to-spoke)

Default Cryptographic Settings

The following tables document Versa's factory default IKE and IPsec settings. These are applied automatically when a new device is provisioned and do not require manual configuration.

2.1  Branch / Hub ↔ Controller Tunnels

Used for control-plane communication between CPE devices (branches and hubs) and the Versa Controller.

IKE Phase 1 (Key Exchange)

IPsec Phase 2 (Data Encryption)

2.2  Branch / Hub ↔ Branch / Hub Tunnels

Used for data-plane overlay traffic between CPE devices. Versa uses AES-GCM (Authenticated Encryption with Associated Data) for this path, which combines encryption and integrity in a single pass for maximum performance.

IPsec (Data Encryption)

Quick Reference Summary

The table below summarizes the default settings across all tunnel types in a single view.

Algorithm Performance Guidance

When selecting encryption and hash algorithms, there is always a trade-off between security strength and throughput. The table below compares common algorithm combinations to guide your selection.

Changing Default IKE and IPsec parameters between Branch and Controllers

5.1  Before Deploying Branches

If you need to customize the IKE or IPsec profile before provisioning branch devices, modify the settings on the Controller first. This ensures all newly provisioned devices negotiate the correct algorithms from the first connection.

1. Log in to Versa Director and navigate to your organisation's template.
2. Open the IKE / IPsec profile and update the Encryption, Hash, and DH Group fields to the desired values.
3. Save and publish the updated template.
4. Deploy branches — they will automatically inherit the updated IKE/IPsec parameters.

5.2  After Branches Are Already Deployed

Changing cryptographic settings on live deployed devices requires a coordinated sequence to avoid tunnel outages. Follow these steps carefully:

1. Update the IPsec VPN profile on template in Director.
2. Push the updated template to Hub/Branches nodes first with the Reboot option enabled.
3. Apply the same template change to all branch/hub devices using the reboot push option.
4. Verify Controller tunnels re-establish successfully with the new parameters.
5. Monitor tunnel state in Director — all devices should show Connected status within 10 minutes of reboot.

If tunnels do not re-establish, check that the IKE and IPsec proposals on both ends match exactly. Mismatched DH groups are the most common cause of negotiation failure after a cipher change.

Changing Default IPsec parameters between Branch/Hub and Branch/Hub

If you need to modify the default IPsec encryption or integrity algorithms (for example, changing from the Versa default AES-128-GCM), update the Branch-to-Branch SD-WAN profile accordingly.

To ensure uninterrupted connectivity during the transition, follow these steps:

1. Create a new transform-set with the desired encryption and integrity algorithms.
2. Retain the existing AES-128-GCM transform-set and configure both transform-sets in the SD-WAN profile.
3. Push the updated profile to all required Branch/Hub devices.
4. After confirming that tunnels are successfully established using the new transform-set, remove the default AES-128-GCM transform-set from the profile.

This staged approach prevents tunnel disruption by ensuring that both peers maintain at least one mutually supported proposal during the migration process.

Diffie-Hellman Groups & Perfect Forward Secrecy

All Versa SD-WAN tunnels use Perfect Forward Secrecy (PFS) by default. PFS ensures that even if a long-term private key is compromised, past session keys cannot be derived — every IPsec SA uses a fresh Diffie-Hellman exchange.

Group 19 (ECDH — NIST P-256)

Versa defaults to DH Group 19, which uses Elliptic Curve Diffie-Hellman (ECDH) over the NIST P-256 curve. This offers equivalent security to a 3072-bit RSA key while using significantly smaller key sizes, resulting in faster negotiation and lower CPU overhead.

Frequently Asked Questions

Why does Versa use GCM for Branch-to-Branch but SHA-256 for Branch-to-Controller?

Branch-to-Branch tunnels carry high-volume data-plane traffic where throughput and scalability are critical. AES-GCM (AEAD) integrates encryption and integrity in a single operation, eliminating separate HMAC computation and reducing CPU overhead at scale.

Branch-to-Controller tunnels primarily handle control-plane and management traffic at significantly lower volumes. In this context, SHA-256 provides strong, auditable integrity verification without material performance impact.

Is it safe to mix AES-128 and AES-256 devices in the same deployment?

Yes, provided both endpoints include the other's cipher in their IKE proposal list. During negotiation, IKE will automatically select the strongest mutually supported algorithm.

However, for operational consistency and simplified troubleshooting, Versa recommends standardizing on a single cipher suite within the same network segment.

What happens if IKE parameters mismatch after a cipher change?

If IKE parameters do not match between peers, tunnel negotiation will fail and the tunnel will not establish. Device logs will typically display the error:

NO_PROPOSAL_CHOSEN

To prevent this condition:

1. Update Controllers first.

2. Verify successful tunnel establishment.

3. Then push configuration changes to Branch devices.

This ensures both ends maintain compatible active proposals during the transition.

AES-256-GCM vs AES-256 + SHA-256 — Which Should I Use?

Recommendation: Use AES-256-GCM.

AES-256-GCM provides integrated encryption and integrity (AEAD) in a single operation and benefits from hardware acceleration on modern CPUs. This results in better performance, lower CPU utilization, and improved scalability.

AES-256 + SHA-256 remains cryptographically strong but requires separate encryption and HMAC processing, introducing measurable performance overhead without providing additional practical security benefits.

Use AES-256 + SHA-256 only when required for regulatory compliance or legacy interoperability.

AES-256-GCM vs AES-256 + SHA-384 — Which Is More Secure?

Recommendation: AES-256-GCM remains the preferred option.

Although SHA-384 uses a larger hash size, it does not provide meaningful additional security in typical enterprise SD-WAN deployments. Overall security strength is generally bounded by the encryption algorithm and key exchange parameters.

AES-256 + SHA-384 introduces significant performance overhead due to separate HMAC computation. Unless mandated by regulatory requirements, AES-256-GCM is the better choice.

AES-256-GCM vs AES-256 + SHA-512 — Is SHA-512 Stronger?

Recommendation: AES-256-GCM is preferred.

SHA-512 does not increase the effective encryption strength beyond AES-256. In practical deployments, AES-256-GCM already delivers strong authenticated encryption with significantly better performance and lower CPU utilization.

AES-256 + SHA-512 should be used only when explicitly required by customer security or regulatory policies. For modern deployments, AES-256-GCM provides the optimal balance of security, performance, and efficiency.