Industrial equipment behind NAT can often be reached without static port forwarding by placing a managed connector or gateway near the equipment and having it initiate an outbound session to a broker, relay, or private overlay. The remote user authenticates to the access service and receives a path only to an authorized target. This avoids depending on a standing inbound translation rule, but it does not remove the need for egress restrictions, segmentation, protocol testing, and a defined failure policy.
The safest target is usually not “the factory network.” It is one web HMI, one remote desktop workstation, one SSH service, or one carefully bounded industrial protocol endpoint. Starting with that resource changes the design from internet reachability to controlled access.
Why does NAT make inbound industrial access difficult?
Network address translation lets many private addresses communicate through one or more public addresses. When an internal device starts a connection, the NAT device creates state that maps the private flow to an external address and port. An unsolicited inbound connection has no matching state unless an administrator creates a static mapping, uses a traversal mechanism, or the application maintains an outbound session.
NAT behavior is not identical across devices. Mapping lifetimes, filtering, UDP handling, port preservation, and behavior under multiple layers can differ. The IETF’s RFC 4787 defines terminology and behavioral requirements for unicast UDP NAT, but a real industrial site may also involve carrier-grade NAT, stateful firewalls, explicit web proxies, DNS filtering, TLS inspection, or a mobile connection that changes public address.
This is why “works behind NAT” is not a sufficient acceptance test. A solution must work behind the site’s NAT and security controls, with the exact transport and reconnect behavior the operations team can support.
How can outbound-initiated remote access work?
The site-side component starts an allowed outbound connection and keeps enough state for authorized return traffic. A remote client connects to a known service, establishes identity, requests a target, and the service coordinates or relays the two sides. Depending on the product, traffic may use a broker, a relay, a peer-to-peer overlay, an application proxy, or a combination.
| Pattern | Site-side behavior | What remote users receive | Important validation point |
|---|---|---|---|
| Brokered application proxy | Connector maintains an outbound control or data path | Access to a named web app, desktop, SSH host, or service | Supported protocols, proxy trust boundary, and what the broker can see |
| Relayed reverse tunnel | Gateway opens an outbound tunnel to a relay | A mapped path back to one local target | Destination restrictions, relay security, tunnel lifetime, and credential handling |
| Private overlay or mesh | Site node joins an authenticated virtual network | Routes or service identities within the overlay | Route scope, peer authorization, NAT traversal fallback, and lateral movement controls |
| Outbound remote desktop agent | Managed workstation connects to a rendezvous service | Screen and input access to that workstation | Local privilege, file and clipboard controls, software abuse detection, and unattended-access policy |
| Site-initiated VPN | Site gateway maintains a tunnel to a hub | Selected remote networks or subnets | Routing boundaries, hub compromise impact, overlapping addresses, and rule ownership |
These patterns can avoid a static inbound port-forwarding rule, but they do not all create the same trust model. Some relays terminate application sessions; some transports protect traffic between endpoints; some overlays give network routes; and some proxies expose only one application. Document the encryption endpoints, authentication parties, metadata visibility, and administrative control plane instead of assuming every “tunnel” has end-to-end properties.
What does a practical reference architecture look like?
A defensible design has five layers:
- Remote endpoint: an approved named user, or the holder of a separately issued bearer credential, runs the client or browser on an assessed endpoint.
- Identity and policy: named-user access authenticates a person and checks the requested resource. A bearer link instead treats possession of the link as the credential, so distribution, expiry, and revocation need separate controls.
- Broker, relay, or overlay control plane: it coordinates the session and enforces the target and policy model chosen for that access path.
- Site connector or gateway: a maintained system in an appropriate boundary zone initiates only documented outbound connections.
- Local target policy: a firewall or host rule permits the connector to reach only the intended HMI, workstation, application, or PLC service.
The gateway should not become an unrestricted bridge. If it can reach every VLAN and accept arbitrary destinations, the architecture has recreated broad network access through an outbound tunnel. Use separate connectors, interfaces, routes, or policy groups where consequence and ownership differ.
The NIST Guide to OT Security discusses segmentation, remote access, and controls in the context of OT reliability and safety. Its central lesson for this design is that a connectivity mechanism must fit the industrial topology and operational consequence; a generic IT deployment pattern is not enough.
Where should the connector be placed?
Do not make a PLC the internet access endpoint. Controllers often have long service lives, limited security functions, and strict availability requirements. Place the connector on a maintained industrial edge device, access gateway, or controlled workstation with only the local connectivity it needs.
For a web HMI, the gateway may proxy a single HTTPS service. For PLC engineering, a better path may terminate at a managed engineering workstation that already has the vendor software, with downstream rules from that workstation to the controller. For remote monitoring, publish the historian or a read-only application rather than exposing the control protocol merely because it is technically possible.
The ISA/IEC 62443 approach treats industrial cybersecurity as a shared, lifecycle responsibility. Apply that thinking to placement: the asset owner defines the zone and consequence, the integrator documents conduits and allowed flows, the product supplier explains security behavior, and the service provider operates within those boundaries.
Which firewall and egress rules are actually needed?
Outbound-initiated does not mean “allow the gateway to reach the internet.” Obtain an exact deployment sheet from the supplier and record:
- destination hostnames and whether stable IP ranges are available
- TCP and UDP ports, plus which functions fail if UDP is blocked
- DNS resolvers and certificate validation requirements
- compatibility with explicit proxies and TLS inspection
- primary, failover, telemetry, update, and time-synchronization endpoints
- whether the product can be pinned to an organization-specific tenant or relay
- update signing and the operational process for gateway patches
- expected keepalive intervals and session behavior after link changes
Permit only what is required and monitor rejected traffic during the pilot. If wildcard destinations or unrestricted outbound access are required, record that as a risk rather than hiding it inside a broad rule.
NIST’s remote access security guide, SP 800-46 Rev. 2, recommends treating remote access components as part of the security boundary and securing client devices, servers, and communications. Although much of the guide addresses enterprise remote work, that boundary mindset applies directly to an outbound industrial gateway.
Does avoiding port forwarding make the design secure?
No. Removing a static inbound mapping reduces one form of exposure, but a compromised connector can still create an authorized-looking outbound path. Stolen user credentials can still be abused. An overly broad local route can still allow lateral movement. A vulnerable control plane can still affect many sites.
Use phishing-resistant multifactor authentication where practical, unique identities, least-privilege target policy, maintained endpoints, fast access removal, and monitoring appropriate to the architecture. Also inventory other remote tools already installed. CISA’s Principles of OT Cyber Security asks organizations to make decisions around the unique operational and business consequences of OT, rather than treating cyber controls as a purely technical layer.
NAT itself is not identity or authorization. It may block unsolicited traffic as a consequence of stateful behavior, but security depends on explicit filtering and the systems that are allowed to create outbound state.
How should you test double NAT, CGNAT, and restricted sites?
Use the intended hardware and network, not a permissive office lab. Test at least these conditions:
- normal connection through the site firewall and NAT
- double NAT and, where relevant, carrier-grade or mobile NAT
- UDP blocked so the product must use its documented fallback
- an explicit proxy that requires authentication
- TLS inspection enabled and disabled according to site policy
- DNS unavailable, slow, or returning changed addresses
- public address change while a session is active
- brief link loss followed by reconnect
- broker or relay unavailable
- user access removed during or before a new session
- attempted access to a neighboring, unauthorized resource
Record whether sessions fail closed, how long reconnect takes, what local services continue, and who receives actionable status. The 2026 NIST NCCoE OT remote access build architecture is a useful primary reference because it presents remote access as a set of implementable architectures and operational choices rather than a single abstract control.
What is the commissioning checklist?
Before production use, confirm:
- the connector has a named owner, supported operating system, and documented update process
- local firewall rules name exact sources, targets, and services
- remote roles correspond to real support tasks
- vendor access can be removed promptly; use expiry when the business case calls for it
- PLC changes still require the site’s maintenance, backup, validation, and rollback procedure
- control continues safely if the connector, internet, DNS, or external service is unavailable
- recovery does not depend solely on the same remote path that failed
- diagrams show NAT, firewall, proxy, relay, gateway, and OT zone boundaries
- incident responders know how to disable the path without disabling the process
For a broader method comparison, see OT remote access vs VPN, jump server, and ZTNA. If the target is a controller or operator interface, continue with the secure remote PLC and HMI support architecture. Use the industrial remote-access rollout checklist as the implementation hub.
When is this architecture not a good fit?
An outbound broker or overlay is not appropriate when policy requires a true air gap, when the site cannot permit the necessary egress, or when dependency on an external control plane exceeds the availability tolerance. Direct remote control of safety functions, latency-critical closed-loop control, and unsupported proprietary protocols also need a different design or an on-site procedure.
Highly restricted organizations may choose a locally supervised maintenance workstation with removable media controls and no standing remote path. Others may require a self-hosted broker or site-to-site circuit. “No port forwarding” is an implementation constraint, not a reason to weaken a stronger operational requirement.
Where might Orenda fit?
Orenda Connect can be evaluated when named organization users should reach approved apps, devices, servers, or industrial resources without broad network-level access. Orenda Box can provide a maintained on-site location for local apps and machine connectivity. For outside support, an Orenda vendor link is a target-scoped bearer credential: possession grants the link’s access, optional expiry can be configured, and an authorized organization user can revoke it. It does not authenticate the individual holder. Those product roles do not, by themselves, guarantee that every deployment avoids inbound exposure or works through every NAT, proxy, and firewall combination.
Treat an Orenda pilot like any other architecture review: validate the exact site egress, gateway placement, target and protocol scope, encryption trust boundaries, identity behavior, loss-of-connectivity behavior, and evidence needs. Vendor access can be target-scoped and revoked, with optional expiry, but the asset owner must still supply the request, authorization, change-control, and operational supervision process.
