Comparison · Networking and Wi-Fi
Route-Based versus Policy-Based IPsec VPN
Policy-based IPsec protects packets matching traffic selectors. Route-based VPN exposes a tunnel interface and routing as an operational model. Peer traffic-selector constraints and…
Technical review:
Architecture and operating model
Policy-based IPsec protects packets matching traffic selectors. Route-based VPN exposes a tunnel interface and routing as an operational model. Peer traffic-selector constraints and firewall policy still matter.
Route-based operation can simplify multiple subnets and dynamic routing. Legacy devices or narrow selector requirements may favor policy-based compatibility. Verify interface support, NAT exemption, IKE/Child-SA behavior and route distribution for each platform version.
- 1Traffic selection
- 2Route/tunnel interface
- 3IPsec SA
- 4Remote network policy
Design parameters
- Subnet changes
- Record whether adding a subnet changes selectors, routes and security policies.
- Failover
- Routes can change while SAs remain established; tunnel status alone does not demonstrate application reachability.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Criterion | Route-based | Policy-based |
|---|---|---|
| Path selection | Tunnel interface/route | Traffic selector |
| Growth | Route management becomes central | Selector pairs can grow |
| Compatibility | Requires interface and peer support | May suit legacy peers |
Worked example
Six headquarters subnets and four branch subnets produce up to 24 traffic pairs if configured separately. Actual SA counts depend on support for multiple selectors per SA. Route-based routing may simplify configuration, but the same authorization matrix must remain.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| SA up, one-way traffic | Selector, return-route or NAT mismatch. | Compare encrypted/decrypted counters at both ends. |
| New subnet unreachable | Missing route or selector/policy. | Inspect route lookup and Child-SA coverage. |
Acceptance checks
- Test selector compatibility on both platforms.
- Verify NAT behavior.
- Preserve the subnet authorization matrix.
- Test MTU.
- Measure application behavior during failover.
- Exercise subnet onboarding.
Related concepts
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
IT/OT security zones
A zone groups assets with similar operational and security requirements; communications between zones should traverse controlled conduits. An accessible OT device is not necessarily safe to scan or update. Control latency, safety, vendor support and maintenance windows influence decisions. Observe actual PLC and SCADA flows rather than copying IT policies unchanged. Define identity, duration, approval and logging requirements for remote support, and coordinate active tests and cutovers with production owners.
MTU along the path
MTU concerns packet size on a link; tunnelling and encapsulation headers can reduce space available for useful payload. Small requests working while large transfers stall may suggest an MTU issue, but this is not proof. TCP MSS and interface MTU are distinct. Compare both endpoints and tunnel interfaces. Identify the affected segment with controlled tests instead of changing every device, and remember that blocked ICMP error messages can complicate path-MTU discovery.
Encryption and key lifecycle
Encryption makes data difficult to read without its key; access control, deletion protection and backup address different needs. Identify which layer protects data in transit and data at rest. Key generation, protection, rotation and emergency recovery are part of the design. A key needed to restore a backup must not exist only on the server that could be lost in the incident. Test decryption and key-access recovery using a separate administrator in a lab, and keep real keys out of documentation and support messages.
Failover and failback
Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behaviour and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.