Purpose

This Knowledge Base documents validated IPsec (IKEv2) interoperability patterns between ZPE Nodegrid appliances and commonly deployed third‑party platforms:

• Cisco (ISR / ASA / IOS‑XE)
• Palo Alto Networks
• Cisco Meraki MX

It is based on:

• Hands‑on lab validation using Nodegrid 6.0.33+
• Customer screenshots and production troubleshooting
• Real‑world escalation involving Meraki + NAT behavior

The goal is to eliminate ambiguity around:

• Required vs. optional fields
• Route‑based (VTI) behavior
• Vendor‑specific requirements not clearly documented elsewhere

Supported Architecture (Required)

ZPE Nodegrid supports route‑based IPsec only, implemented using a Virtual Tunnel Interface (VTI).

Key characteristics:

• IKEv2 only
• Traffic selection is routing‑based (not policy‑based ACLs)
• Dynamic routing (e.g., BGP) is supported over the tunnel
• Phase‑2 selectors are typically ANY/ANY, unless the peer enforces otherwise

This architecture is supported and recommended for all vendors covered in this document.

Firmware Scope

This guide applies to:

• Nodegrid firmware 6.0.33 and later

Important note:

• Older ZPE KBs reference prerequisites that are no longer required
• Full IPsec configuration can now be completed entirely via WebUI

Common Terminology Mapping

Critical Clarification: Local & Remote Subnets

Older documentation stated that local/remote subnets were optional for route‑based VPNs.

Updated, validated guidance

• ✅ Nodegrid itself does not require subnets for route‑based tunnels
• ✅ Cisco and Palo Alto generally do not enforce subnets
• ⚠️ Cisco Meraki MX DOES REQUIRE subnets, even for route‑based VPNs

Why this matters

Meraki uses “local networks” and “remote networks” to:

• Build Phase‑2 selectors
• Validate tunnel completeness
• Maintain tunnel stability

Practical rule

When peering Nodegrid with Meraki, always define local and remote subnets.

These may be:

• Loopbacks (/32), or
• Small RFC1918 ranges used only for tunnel validation

Meraki + NAT: Undocumented but Critical Behavior

Summary (Very Important)

In environments where NAT exists between Nodegrid and Meraki, Cisco Meraki enforces stricter IKE identity behavior:

• IP‑based IKE IDs that work in lab may fail in production
• FQDN‑based IKE IDs are required when NAT is present

This behavior:

• Is not documented by Cisco Meraki
• Was confirmed only after engaging Cisco TAC
• Explains discrepancies between lab and production results

Required configuration when Meraki + NAT is involved

• Use FQDNs for:
  • Left ID
  • Right ID
• Do not rely on IP addresses as IKE identities
• Ensure IDs match exactly on both peers

Best practice recommendation

For all Meraki deployments—especially production—use FQDN‑based IKE IDs by default.

Validated Nodegrid Configuration Pattern

The following configuration was validated end‑to‑end using customer screenshots and lab testing.

1. Endpoint Preparation

• Confirm public IP reachability between peers
• Create a loopback interface on each Nodegrid
• Verify each Nodegrid can ping its own loopback

2. Nodegrid IPsec Tunnel Settings

Local (Left) Side

• Left Address: External (WAN) interface IP
• Left ID:
  • Cisco / Palo Alto: IP or FQDN
  • Meraki + NAT: FQDN required
• Left Source IP: Local loopback IP
• Left Subnet:
  • Required for Meraki
  • Optional for others (but safe to define)

Remote (Right) Side

• Right Address: Remote external IP
• Right ID:
  • Must match peer expectations
  • Use FQDN for Meraki with NAT
• Right Source IP: Remote loopback IP
• Right Subnet: Required for Meraki

3. IKE Profile

• IKEv2
• Same profile on both sides
• Same pre‑shared key

Recommended baseline

• AES‑256
• SHA‑256
• DH Group 14 or higher
• Lifetime ~28800 seconds

Changing the IKE profile on one side will drop the tunnel; matching it restores the tunnel immediately. This behavior is expected.

Vendor‑Specific Notes

Cisco (ISR / ASA / IOS‑XE)

• Route‑based VTI supported
• Subnets typically not enforced
• Most common failures:
  • Firewall blocking UDP 500 / 4500 or ESP
  • IKE ID mismatch

Palo Alto Networks

• Route‑based VPN only
• No proxy‑IDs required
• Tunnel interface IP must exist
• Security policy must allow:
  • IKE
  • IPsec / ESP

Cisco Meraki MX (Summary)

• Local and remote subnets required
• NAT + IP‑based IDs can cause instability
• Use FQDN‑based IKE IDs in production
• Configuration may work in lab but fail in prod without this adjustment

Common Failure Modes (Observed)

Recommended Bring‑Up Order

1. Agree on IKE parameters and IDs
2. Define loopbacks and (for Meraki) subnets
3. Bring up tunnel
4. Verify loopback reachability
5. Add routing or BGP
6. Apply firewall tightening if required

Final Summary

Nodegrid IPsec behavior is correct, consistent, and standards‑based.
Most issues encountered in real deployments stem from peer‑specific expectations, not Nodegrid limitations.

Key rules to remember

• Route‑based IPsec (VTI) is required
• Meraki always needs subnets
• Meraki + NAT → FQDN‑based IKE IDs
• When in doubt, favor explicit configuration over relying on “optional” behavior

This KB replaces older guidance and should be used as the authoritative reference for all Nodegrid IPsec turn‑ups.