Choose OPNsense nginx SNI pass-through or TLS termination explicitly

Bottom line: Draw the TLS boundary before selecting an upstream. Keep an SNI pass-through design separate from a design that decrypts at the firewall and establishes a new backend connection.

Source fact: what the authority says

The OPNsense nginx stream guide describes pass-through routing based on SNI and a read-and-forward mode that can terminate TLS. With an SNI Upstream Map, the connection is not decrypted on OPNsense, so the guide says a TLS connection cannot be load-balanced to an unencrypted server. For termination, the guide directs selecting a certificate; when routing directly with the upstream property, upstream TLS settings determine whether the backend connection is encrypted again. Proxying UDP datagrams requires the UDP Port checkbox, and the guide excludes protocols requiring special handling such as FTP or SIP.

What the source does not establish

This article concerns the stream modes described by the OPNsense plugin guide. It does not qualify an encrypted-client-hello deployment, approve weakening a client privacy feature or establish application compatibility from a routing example.

Applicability questions

• Must TLS remain end to end to the selected server, or may this firewall terminate it?
• Which certificate owner and hostname belong to each intended TLS endpoint?
• Does the backend expect encrypted or unencrypted traffic?
• Is the proposed stream TCP or UDP, and does it require protocol-specific handling?

DSE recommendation: controlled next steps

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

DSE recommends a connection drawing with the client, OPNsense stream listener and selected backend on separate rows. Mark where decryption is intended and name the responsible certificate owner. Have the application owner approve that boundary before populating an upstream map or choosing a listener certificate.

For a proposed SNI pass-through case, require an explicitly encrypted backend endpoint in the worksheet. Review the hostname-to-upstream mapping against that endpoint. Do not convert a server to an unencrypted listener simply to make an apparently similar reverse-proxy example fit the diagram.

For a separately approved termination case, document the client-facing certificate and the intended backend TLS choice independently. Keep trust and identity checks in the application acceptance plan. Resolve any requirement that the firewall must not see plaintext before selecting this branch.

Name the transport protocol and service port before the pilot. Set aside an unusual application protocol for its own supported design review rather than assuming all TCP traffic is interchangeable. Preserve the current stream definitions so the approved test can return to the previous listener without an unrelated certificate or application change.

Verification and evidence

Proposed verification: use a permitted test hostname and harmless transaction for each selected branch. Inspect the certificate presented to the client and correlate the chosen backend with the saved mapping. For the termination branch, inspect the effective backend encryption configuration separately from the client-facing result.

Include a second hostname mapped to a different approved test backend so the observer can distinguish routing from mere listener availability. Record the selected mode, transport and backend identity with each result. Treat unexpected certificate presentation or an unreviewed plaintext boundary as a stop condition before expanding the listener.

Official references

• OPNsense — nginx: TCP And UDP Streams — official product documentation; confirm the installed release and configuration.

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