# Bind OPNsense NAT-before-IPsec policies to the intended tunnel > Choose the fixed request-ID or dynamic Child binding branch for manual IPsec policies before accepting the BINAT mapping. - Canonical URL: https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:47+00:00 - Modified: 2026-10-30T06:05:13+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Choose the fixed request-ID or dynamic Child binding branch for manual IPsec policies before accepting the BINAT mapping. ## Potentially affected OPNsense policy-based NAT-before-IPsec deployments following the documented Connections workflow. ## DSE recommendation Review manual-policy tunnel binding and the approved network map before applying BINAT. ## Article Bottom line: Choose the manual-policy binding branch before applying the translation. Keep the intended child connection, actual local network and remote-visible network explicit instead of copying a numeric example. ## Source fact: what the authority says The [OPNsense NAT-before-IPsec guide](https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html) requires the tunnel to be running before configuring NAT and uses a static child request ID to bind manual policies to that tunnel. After a manual security-policy change, the guide calls for reconnecting the tunnel because registration occurs through an updown event. For multiple clients using the same child with a pushed remote network, it describes a dynamic request ID left blank in the child and direct binding through the manual policy’s Child option. Its one-to-one IPsec BINAT example requires equally sized networks. ## What the source does not establish This article addresses manual-policy binding for the documented NAT workflow, not the routed VTI setup or a universal translation design. It does not approve the page’s sample source addresses as a deployment address plan. ## Applicability questions - Which actual child connection will own the manual policies? - Does the scenario use a fixed request ID or the documented dynamic Child branch? - What local and remote-visible networks have both tunnel owners approved? - When will the required reconnect occur and how will service recovery be handled? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends a tunnel-binding worksheet that separates connection identity, child selection, request-ID choice and translation ranges. Resolve the fixed versus dynamic branch before entering a manual policy. Have both tunnel owners review the intended mapping and reject a worksheet assembled from unmatched numeric examples on the source page. For a fixed-ID proposal, reconcile the actual child and manual-policy references together. For the documented shared-child scenario, review the explicit Child selection instead of inventing a permanent number. Keep those alternatives separate in the plan; do not combine a routed VTI procedure with this policy-based NAT workflow. Prepare proposed local and remote test endpoints with harmless traffic and an approved equally sized mapping. Name the expected original and translated identities in each direction. Ask the remote owner to confirm the same address plan before scheduling the change, including any destination that must remain outside the intended mapping. Include the guide’s reconnect requirement in the maintenance sequence and obtain an interruption allowance from the service owner. Preserve the existing policy and translation configuration. Stop if the observed tunnel or child differs from the worksheet rather than applying additional rules to conceal a binding mistake. ## Verification and evidence Proposed verification: inspect the actual child, selected binding branch and manual-policy references against the worksheet after the planned reconnect. Record the tunnel state and effective mapping without assuming that an established tunnel proves the manual policies are attached correctly. Investigate any unexpected request-ID or Child association first. Exercise the approved endpoint cases with the remote owner and retain original and translated address observations from the agreed locations. Include the excluded control destination. Reconcile return traffic and unresolved failures with the selected policy before accepting the change; keep broader routing and application compatibility outside this bounded result. ## Official references - [OPNsense — IPsec – NAT before IPsec](https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html) — official product documentation; confirm the installed release and configuration. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: OPNsense — IPsec - NAT before IPsec - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bind OPNsense NAT-before-IPsec policies to the intended tunnel,” DSE Security, https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/ 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.