# Check OPNsense IPsec VTI request IDs and policy mode together > Reconcile VTI and child request IDs and the guide’s no-installed-policies branch before accepting the routed IPsec configuration. - Canonical URL: https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T20:33:06+00:00 - Modified: 2026-10-29T20:33:35+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Reconcile VTI and child request IDs and the guide’s no-installed-policies branch before accepting the routed IPsec configuration. ## Potentially affected OPNsense site-to-site routed IPsec deployments following the Connections/VTI PSK example. ## DSE recommendation Review the VTI, child, gateway and route together while preserving independent firewall access. ## Article Bottom line: Reconcile the VTI and child configuration before applying the routed tunnel. Keep the guide’s no-installed-policies warning and the site-specific gateway and route plan in the same review. ## Source fact: what the authority says The [OPNsense routed-IPsec PSK guide](https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html) attaches the virtual tunnel interface to a security policy through its request ID, or reqid. The request ID should be unique among configured if_ipsec(4) tunnels; the guide’s value 10 is arbitrary. Its child example uses matching request ID 10, unchecked Policies and local and remote selectors of 0.0.0.0/0. The guide warns that installed policies without a passthrough can trap traffic in the tunnel and make the firewall inaccessible. It separately configures gateways to the opposite tunnel endpoint and routes to the remote network. ## What the source does not establish This article addresses the specific routed Connections/VTI example, not a universal policy choice for every IPsec deployment. It does not approve copying the example networks, shared secret or request ID into an existing tunnel inventory. ## Applicability questions - Which request ID is allocated to this tunnel, and is it already used? - Do the VTI and child refer to the same intended connection? - Does the proposed configuration follow this guide’s policy branch? - Which gateway, remote subnet and independent recovery path have been approved? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends a tunnel card with the VTI request ID, child request ID, local and remote tunnel addresses, gateway and routed network. Compare it with every configured tunnel identifier before choosing a new value. Keep the shared secret in controlled custody and use only a credential reference on the card. Have a second administrator review the child policy setting and management-access consequence before applying the connection. Do not enable installed policies merely because a different IPsec example does so. If the required topology differs from this routed example, obtain a supported design review rather than combining incompatible steps. Prepare gateways and remote-network routes from the approved site address plan. Give both ends their own checked entries rather than copying one endpoint wholesale. Record the expected forward and return paths and identify the services that should be reachable after the tunnel is active. Keep console or another independent firewall access method available for the pilot. Preserve the starting connection, routing and filter configuration. Agree which operator can revert the tunnel change if management reachability or an unrelated route changes; do not rely solely on the connection being modified. ## Verification and evidence Proposed verification: inspect the saved VTI and child request IDs and policy selection before generating test traffic. Compare each gateway and route with the tunnel card. Observe tunnel status on both ends, then attempt a harmless approved transaction to the named remote network. Check the actual return path and firewall access independently from the tunnel-established indicator. Include a permitted control check to a service outside the intended remote network. Record any unexpected captured route or lost management path as a stop condition, retaining the configuration state that produced it. ## Official references - [OPNsense — IPsec – Route based (VTI) PSK setup](https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html) — official product documentation; confirm the installed release and configuration. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: OPNsense — IPsec - Route based (VTI) PSK setup - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check OPNsense IPsec VTI request IDs and policy mode together,” DSE Security, https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.