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.
\nThe OPNsense routed-IPsec PSK guide 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.
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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nHave 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.
\nPrepare 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.
\nKeep 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.
\nProposed 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.
\nCheck 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense routed-IPsec PSK guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich request ID is allocated to this tunnel, and is it already used?\nDo the VTI and child refer to the same intended connection?\nDoes the proposed configuration follow this guide’s policy branch?\nWhich gateway, remote subnet and independent recovery path have been approved?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nHave 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.\nPrepare 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nOPNsense — IPsec – Route based (VTI) PSK setup — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which request ID is allocated to this tunnel, and is it already used?\n\n- Do the VTI and child refer to the same intended connection?\n\n- Does the proposed configuration follow this guide’s policy branch?\n\n- Which gateway, remote subnet and independent recovery path have been approved?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nHave 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.\n\nPrepare 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.\n\nKeep 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCheck 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/", "url": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check OPNsense IPsec VTI request IDs and policy mode together", "item": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/#article", "identifier": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/", "url": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/", "headline": "Check OPNsense IPsec VTI request IDs and policy mode together", "description": "Reconcile VTI and child request IDs and the guide’s no-installed-policies branch before accepting the routed IPsec configuration.", "abstract": "Reconcile VTI and child request IDs and the guide’s no-installed-policies branch before accepting the routed IPsec configuration.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense routed-IPsec PSK guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich request ID is allocated to this tunnel, and is it already used?\nDo the VTI and child refer to the same intended connection?\nDoes the proposed configuration follow this guide’s policy branch?\nWhich gateway, remote subnet and independent recovery path have been approved?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nHave 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.\nPrepare 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nOPNsense — IPsec – Route based (VTI) PSK setup — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T20:33:06+00:00", "dateModified": "2026-10-29T20:33:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-opnsense-ipsec-vti-request-ids-and-policy-mode-together/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check OPNsense IPsec VTI request IDs and policy mode together" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 541, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — IPsec - Route based (VTI) PSK setup", "url": "https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html" } } ] } }