Distinguish OPNsense hairpin clients from routed reflection clients

Bottom line: Draw the client and server subnets before changing reflection settings. Test a routed internal client and a client beside the server as different cases, even when both use the same public service address.

Source fact: what the authority says

The OPNsense reflection guide defines reflection NAT as the case where client and server are in different subnets and OPNsense routes between them; that case needs DNAT. It defines hairpin NAT as the same-subnet case and says that case needs both SNAT and DNAT. The guide explains that the additional hairpin source translation avoids asymmetric traffic between clients and servers in the same layer-two broadcast domain. It recommends its manual-rule Method 1 over the legacy reflection options so the rules remain visible in the interface and configuration exports.

What the source does not establish

These statements concern the topology and rule model in this OPNsense IPv4 guide. They do not select an application address plan or establish the behavior of another firewall product. DSE does not treat a successful translation as permission for the underlying application access.

Applicability questions

• Does each internal client share the server’s layer-two subnet, or reach it through a routed interface?
• Which public address and service port are being requested, and which internal address and port should receive them?
• What source address should the server observe for each approved case?
• Which existing translation and firewall rules already apply to those interfaces?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a small topology worksheet with three proposed client locations: genuinely external, internal but routed to the server subnet, and inside the server subnet. For each, write the original destination, intended translated destination and expected return path. Use the same service name and transaction where possible so a difference can be investigated without changing the application test.

Review the routed case before adding source translation to the same-subnet case. Limit any proposed hairpin rule to the approved service, server and source population. Have another administrator reconcile the worksheet with the complete active NAT and filter configuration. Preserve the original rules and agree how to remove the pilot change if observations do not match the design.

Keep rule visibility part of the decision. Avoid combining several documented reflection methods without a reviewed reason. Ask the server owner whether the proposed source-address view is acceptable for its logging and access policy. Resolve that question before expanding the rule to other services or assuming that one successful client represents every internal network.

Label each proposed client location with an interface and subnet identifier. Keep a server-side observation of the client address beside the corresponding network trace. That comparison should remain understandable when the same hostname is used from several different internal segments.

Verification and evidence

Proposed verification: generate a narrowly filtered approved application connection from each of the three locations. Record the resolved address, source and destination tuples, relevant interface and rule observations, and the transaction result. Correlate both directions with timestamps rather than accepting an unlabeled packet capture as the complete explanation.

Compare the routed and same-subnet observations with the translation worksheet. Include an explicitly unauthorized client or service case under the approved test plan and confirm the intended access decision. Keep application identity checks separate from packet translation. Restore the prior configuration if the pilot exposes an unexplained return path or an unintended access result.

Official references

• OPNsense — Reflection and Hairpin NAT — official product documentation; confirm the installed release and configuration.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.