# Attach the OPNsense nginx IP ACL to its intended service object > Creating an nginx IP ACL is separate from attaching it to a location, HTTP server or stream server. Review the actual service object and observed source addresses. - Canonical URL: https://update.dsesecurity.com/updates/attach-the-opnsense-nginx-ip-acl-to-its-intended-service-object/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:49+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 Creating an nginx IP ACL is separate from attaching it to a location, HTTP server or stream server. Review the actual service object and observed source addresses. ## Potentially affected OPNsense nginx deployments using the documented IP-based ACL objects. ## DSE recommendation Verify the ACL attachment and test the intended service object with approved allowed and excluded sources. ## Article Bottom line: Verify where the IP ACL is attached before accepting it as an active restriction. Keep the selected service object and the source addresses actually observed by that path in the same review. ## Source fact: what the authority says The [OPNsense nginx IP ACL guide](https://docs.opnsense.org/manual/how-tos/nginx_ip_acl.html) creates an ACL containing individual addresses or ranges, with a separate default rule in its example. The ACL must then be added to a supported object: an HTTP server, stream server or HTTP location. The location example selects the ACL from a dropdown, saves the location and restarts nginx. The guide warns that carrier-grade NAT can complicate these ACLs and that spoofable UDP source addresses make IP allowlisting unsuitable as the only protection. ## What the source does not establish This article checks the documented ACL object and attachment workflow, not an application identity or authorization design. It does not guarantee client attribution through a proxy or carrier network, or approve public exposure based on an address list. ## Applicability questions - Which HTTP location, HTTP server or stream server is the intended target? - What allowed entries and default action are proposed? - Which source addresses does the actual connection path present? - Does the service require protections beyond an IP-based restriction? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends naming the exact service object in the change request rather than describing the change only as an ACL update. Record the proposed address entries, default action and attachment separately. Ask the service owner to confirm that the selected object is the one clients actually use. Prepare a connection-path diagram covering the approved test client and the service entry point. Identify any carrier or intermediary whose address handling needs investigation. Obtain an actual observation for the test path instead of treating the workstation’s locally displayed address as sufficient evidence for the proposed restriction. Use a small reviewed address population for the initial trial. Specify an allowed case, an excluded case and the ordinary service transaction each should attempt. Keep authentication and application authorization requirements in their own review. Reject a plan that uses this ACL alone to justify exposing sensitive functionality. Preserve the previous attachment and service settings before the approved change. Follow the current guide’s save and restart sequence for the selected object, with an interruption and recovery plan appropriate to the service. Avoid combining the ACL trial with a simultaneous proxy or upstream-address redesign. ## Verification and evidence Proposed verification: inspect the saved ACL and its attachment on the named object, then perform the approved service transactions from both test sources. Record the source address observed at the reviewed point, timestamp and actual result. Distinguish a failed client route from evidence that the ACL excluded a request. Repeat a permitted control transaction after the planned restart and compare the effective object with the diagram. Retain redacted before-and-after settings and unresolved carrier-address questions. Accept only the demonstrated path; require a separate security decision for UDP services or paths whose source identity cannot support the intended restriction. ## Official references - [OPNsense — nginx: IP Based Access Control Lists](https://docs.opnsense.org/manual/how-tos/nginx_ip_acl.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 — nginx: IP Based Access Control Lists - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/how-tos/nginx_ip_acl.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Attach the OPNsense nginx IP ACL to its intended service object,” DSE Security, https://update.dsesecurity.com/updates/attach-the-opnsense-nginx-ip-acl-to-its-intended-service-object/ 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.