Related Ingenix tool
Build and validate a vendor-neutral VPN baseline in your browser.
In this guide
Start with requirements
Before configuring a tunnel, document the two peer addresses, local and remote networks, required applications, expected traffic direction, WAN paths, security requirements and failure objectives.
| Requirement | Record |
|---|---|
| Peers | Public IP/FQDN, interface and upstream path. |
| Networks | Local/remote prefixes and any exclusions. |
| Applications | Protocol, port and expected direction. |
| Availability | Primary/secondary path and failover expectation. |
| Security | Authentication, allowed traffic and logging requirements. |
Route-based vs policy-based
| Approach | Best suited to | Watch for |
|---|---|---|
| Route-based | Multiple prefixes, dynamic routing and resilient designs. | Clear tunnel-interface and routing design is required. |
| Policy-based | Simple fixed connectivity. | Selectors become complex as tunnels multiply. |
Route-based VPNs usually behave more like conventional routed links: the tunnel interface becomes a next hop for routes. Policy-based designs associate traffic directly with the VPN policy. Choose one deliberately and document the model because troubleshooting differs between them.
Addressing and routing
Use non-overlapping private ranges. Static routes may be sufficient for simple links; larger environments can route dynamically over a tunnel interface where supported.
Check both directions. A route existing at the branch does not prove the return path exists at the data centre. Asymmetric routing can also send return traffic through a different security device, causing stateful inspection to drop it.
Routing checklist
- Destination prefix exists on the correct side.
- Next hop/tunnel interface is correct.
- Return route exists.
- More-specific routes are not overriding the VPN route.
- Dynamic routing adjacencies, if used, are established.
- Failover routes have the intended preference.
Firewall policy and NAT
The tunnel being established does not automatically permit application traffic. Apply least-privilege security policy to the actual source, destination, protocol and port requirements.
Decide whether VPN traffic bypasses source NAT. A common failure is a general outbound NAT rule translating traffic before it reaches the VPN policy. Check NAT rules, session tables and security-policy logs while generating one controlled test connection.
Redundancy
For important links, consider independent WAN paths, separate peers or redundant gateways. Do not define redundancy only on paper: prove that routing, tunnel establishment, NAT and application sessions behave correctly after failure.
- Define health checks and route preference.
- Know whether both tunnels may remain established simultaneously.
- Decide whether traffic should fail over automatically or require intervention.
- Test primary WAN loss, gateway loss and restoration.
Monitoring
Monitor more than tunnel “up/down” state. Useful metrics include IKE/Child SA state, packet and byte counters, rekey events, latency, loss, tunnel-interface state and application reachability.
Retain logs long enough to correlate a tunnel failure with WAN, firewall, authentication and routing events. A tunnel can remain established while its underlying application path is broken.
Testing and evidence
- Establish IKE and Child SAs.
- Confirm routes point into the tunnel.
- Confirm the security policy and NAT decision.
- Test one known source/destination pair.
- Test both directions and required applications.
- Test DNS separately from IP connectivity.
- Test MTU-sensitive traffic and large transfers.
- Fail each WAN/gateway path and repeat.
Capture exact timestamps and peer addresses. If behaviour is unexpected, collect VPN logs, route tables, session/NAT information and a short packet capture before making further changes. See the VPN Troubleshooting Guide.