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.
\nThe OPNsense NAT-before-IPsec guide 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nFor 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.
\nPrepare 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.
\nInclude 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.
\nProposed 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.
\nExercise 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense NAT-before-IPsec guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich actual child connection will own the manual policies?\nDoes the scenario use a fixed request ID or the documented dynamic Child branch?\nWhat local and remote-visible networks have both tunnel owners approved?\nWhen will the required reconnect occur and how will service recovery be handled?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nPrepare 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.\nInclude 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.\nVerification and evidence\nProposed 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.\nExercise 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.\nOfficial references\n\nOPNsense — IPsec – NAT before IPsec — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which actual child connection will own the manual policies?\n\n- Does the scenario use a fixed request ID or the documented dynamic Child branch?\n\n- What local and remote-visible networks have both tunnel owners approved?\n\n- When will the required reconnect occur and how will service recovery be handled?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nFor 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.\n\nPrepare 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.\n\nInclude 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.\n\n## Verification and evidence\n\nProposed 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.\n\nExercise 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.\n\n## Official references\n\n- [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.\n\nSource review completed October 30, 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/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/", "url": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/#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": "Bind OPNsense NAT-before-IPsec policies to the intended tunnel", "item": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/#article", "identifier": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/", "url": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/", "headline": "Bind OPNsense NAT-before-IPsec policies to the intended tunnel", "description": "Choose the fixed request-ID or dynamic Child binding branch for manual IPsec policies before accepting the BINAT mapping.", "abstract": "Choose the fixed request-ID or dynamic Child binding branch for manual IPsec policies before accepting the BINAT mapping.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense NAT-before-IPsec guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich actual child connection will own the manual policies?\nDoes the scenario use a fixed request ID or the documented dynamic Child branch?\nWhat local and remote-visible networks have both tunnel owners approved?\nWhen will the required reconnect occur and how will service recovery be handled?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nPrepare 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.\nInclude 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.\nVerification and evidence\nProposed 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.\nExercise 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.\nOfficial references\n\nOPNsense — IPsec – NAT before IPsec — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:47+00:00", "dateModified": "2026-10-30T06:05:13+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/" }, "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/bind-opnsense-nat-before-ipsec-policies-to-the-intended-tunnel/#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": "Bind OPNsense NAT-before-IPsec policies to the intended tunnel" }, "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": 550, "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 - NAT before IPsec", "url": "https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html" } } ] } }