IPsec VPN Configuration Generator

← Back to Tools

Generate site-to-site IPsec VPN configs for Cisco IOS/IOS-XE, ASA, FortiGate, Palo Alto, Juniper SRX, strongSwan/VyOS, UniFi, and pfSense/OPNsense — for one side or both at once. The real value here is the policy-based ↔ route-based interop case: when one side is policy-based (proxy-ID per subnet pair) and the other is route-based (defaults to a catch-all 0.0.0.0/0 selector), phase 2 negotiation fails unless the route-based side's proxy-IDs/traffic-selectors are narrowed to match the policy-based side's exact subnet pairs. This tool computes that automatically and warns you when it kicks in. Everything runs in your browser — nothing is sent anywhere.

IKE / IPsec Parameters

IKE Version

Pre-Shared Key

Phase 1 (IKE SA)

Encryption

Hash

DH Group

Phase 1 Lifetime (seconds)

Phase 2 (IPsec SA)

Encryption

Integrity

PFS Group

Phase 2 Lifetime (seconds)

NAT Traversal

DPD Interval (sec)

DPD Retries

Protected Subnets

Enter each subnet pair once — "Side A" and "Side B" below are mirrored automatically into the correct local/remote direction for each side's config.

Generate

Generate both sides Generate Side A only

Side A

Vendor

VPN Model

Local (WAN) IP

Peer IP

Tunnel/Interface Name

WAN Interface Name

Side B

Vendor

VPN Model

Local (WAN) IP

Peer IP

Tunnel/Interface Name

WAN Interface Name

How the same AES-256/SHA-256/DH14 proposal is spelled per platform — the single most common source of "phase 1 just won't come up" between two engineers who are actually configuring the same algorithms.

Concept	Cisco IOS	ASA	FortiGate	Palo Alto	Juniper SRX	strongSwan
AES-256	aes 256	aes-256	aes256	aes-256-cbc	aes-256-cbc	aes256
SHA-256	sha256	sha-256	sha256	sha256	hmac-sha-256-128	sha256
DH Group 14	group14	group14	14	group14	group14	modp2048
AES-256-GCM	esp-gcm 256	aes-gcm-256	aes256gcm	aes-256-gcm	aes-256-gcm	aes256gcm16

Policy-basedThe IPsec SA is scoped directly to subnet pairs pulled from an ACL/policy — each pair negotiates its own proxy-ID. No tunnel interface involved; matching traffic is pulled into the VPN by the ACL itself.

Route-basedA virtual tunnel interface (VTI / st0 / ipsec interface) carries the SA. Routing (static routes or a routing protocol) decides what traffic enters the tunnel, so the natural default proxy-ID is 0.0.0.0/0 ↔ 0.0.0.0/0.

Mixed pairPairing the two directly fails phase 2 negotiation — the route-based side's 0.0.0.0/0 proposal doesn't match the policy-based side's specific subnet ACL entries. Fix: narrow the route-based side's proxy-ID/traffic-selector to exactly the same subnet pairs the policy-based side is proposing, one entry per pair. This tool does that automatically whenever it detects a mixed pair.

PFS group mismatchPhase 2 fails silently on many platforms if PFS is enabled on one side and disabled (or a different group) on the other.

Lifetime mismatchNot usually fatal — most platforms accept the lower of the two proposed lifetimes rather than failing negotiation. Still worth matching to avoid asymmetric rekey timing.

IKEv1 Aggressive ModeSends the peer's identity and a hash derived from the PSK in the clear during negotiation — avoid unless required for legacy/dynamic-peer interop.

NAT-TIf either peer is behind a NAT device, both sides need NAT-T (UDP 4500) enabled/auto-detected, or the tunnel won't come up at all.

GCM = combined modeAES-GCM provides encryption and integrity together — don't pair it with a separate hash/integrity algorithm; most platforms ignore or reject one.

Overlapping subnetsIf a subnet pair overlaps with another route/tunnel already on either box, expect asymmetric or black-holed routing, not a clean negotiation failure.

This generates a starting point, not a guarantee — always lab-test before touching production, and double-check exact algorithm keyword spelling against current vendor documentation (syntax drifts slightly between OS/firmware versions). See the full disclaimer.