A remote edge gateway sends a request across the WAN, through a firewall or VPN boundary, and into the cloud Ignition gateway. If that path ends at public port 8088, it exposes an HTTP listener to the internet and carries traffic in clear text. Use a VPN as the preferred Gateway Network path. If public access is required, terminate HTTPS/TLS at a hardened endpoint, expose only the required service, and keep PLC polling local to each site.
Where should the edge connection terminate?
Follow the packet from the edge gateway to its destination. A VPN path gives the edge device a private route to the cloud gateway without publishing the Ignition listener directly. A public path sends the connection to the server's public IP address, where the firewall forwards the permitted traffic to Ignition.
| Path | Destination address | Exposed service | Security consequence |
|---|---|---|---|
| VPN | Private address reachable through the tunnel | VPN endpoint is public; Ignition remains private | Reduces direct exposure of the Ignition application |
| Direct public connection | Cloud gateway public IP | Ignition listener on 8088
|
Internet clients can reach the application attack surface |
| Reverse proxy | Public address of the proxy | Selected HTTPS application paths | Separates public web termination from the internal gateway |
TLS protects traffic in transit, a firewall limits reachable services, and certificate authentication checks the connecting edge identity. Those controls do not remove the risk of a previously unknown application flaw. The VPN remains the safer choice because it prevents arbitrary internet clients from reaching Ignition directly.
Check: From an external network, confirm that the public address reaches only the intended VPN or proxy endpoint and does not expose the internal Ignition listener.
Does the physical and routed path work first?
Layer one first. Before changing Gateway Network settings, prove that each edge gateway has a stable WAN path and that routing returns traffic through the same security boundary. Protocol configuration cannot correct an unavailable link, blocked route, or incorrectly forwarded connection.
- Confirm the edge gateway has local connectivity and a route toward the cloud or VPN endpoint.
- Confirm the VPN tunnel establishes when a VPN is used.
- Test reachability to the exact private or public destination selected for the design.
- Check the cloud firewall rule and any intermediate forwarding rule against the intended source, destination, and port.
- Confirm the expected service, rather than an unrelated application, owns the destination listener.
| Check | VPN design | Public design |
|---|---|---|
| Address | Cloud gateway private address | Cloud public IP or proxy address |
| Port exposure | Ignition port remains inside the tunnel | Only the selected public listener is reachable |
| Timing observation | Measure tunnel stability and connection latency | Measure WAN latency and connection stability |
| Failure boundary | Tunnel, route, firewall, then application | Route, firewall, proxy or listener, then application |
Check: Capture or inspect connection diagnostics at both ends and verify that the request reaches the intended endpoint and that the reply returns to the originating edge gateway.
Can port 8088 carry the production connection securely?
On the described path, 8088 carries HTTP and therefore sends application data and credentials without transport encryption. Restricting the firewall to one listening application does not encrypt that traffic. Anyone positioned on a client-side, carrier, or intermediate network path can inspect clear-text credentials.
The port number alone does not provide security; the protocol bound to the listener decides whether the session is encrypted. If the edge devices connect directly over the public internet, configure HTTPS/TLS and verify that clients reject an invalid, expired, or mismatched certificate. Certificate-based edge authentication adds identity control, but it must operate over the intended encrypted endpoint.
- Remove public access to the clear-text HTTP listener.
- Configure the TLS certificate on the selected public termination point.
- Configure each edge gateway to use the encrypted address.
- Restrict the firewall to the minimum required listener and expected sources where practical.
- Require the configured certificate authentication before accepting an edge connection.
Check: Connect from an external test network, verify that the session negotiates TLS, confirm the certificate identity, and prove that a clear-text request to public 8088 cannot reach the gateway.
Should public Perspective access share the edge path?
Machine-to-machine Gateway Network traffic and human Perspective access have different exposure and authorization requirements. Do not publish the complete internal gateway merely because users need selected production screens.
Place a proxy server such as nginx in reverse-proxy mode on the internet-facing side. Configure it to forward only the selected Perspective project URLs to the internal Ignition server. Keep designer access, unrelated applications, and other gateway functions off the published route. User login still controls identity; project permissions must limit what an authenticated user can view or operate.
| Setting | Edge gateway traffic | Public Perspective traffic |
|---|---|---|
| Preferred entry point | VPN endpoint | HTTPS reverse proxy |
| Allowed destination | Gateway Network service | Selected project URLs |
| Authentication | Configured certificate authentication | User login and project authorization |
| Internal services published | None outside the tunnel | Only explicitly proxied web paths |
Check: From outside the network, open an allowed project URL, reject an unauthorized login, and confirm that designer access and nonpublished project paths remain unreachable.
Where should PLC polling occur?
Keep protocol drivers and PLC polling at the site containing the PLCs. Direct polling from a remote cloud gateway adds WAN latency and variability to every request-response exchange. Slow or interrupted links then affect scan performance, multiply bandwidth use, and make device communication dependent on the wide-area connection.
Use a local box with the required drivers or MQTT capability. It reads the PLCs over the local controls network and sends collected data to the cloud. MQTT is the stated preferred transport for this topology. An OPC UA connection from the cloud gateway to the edge gateway is another workable path, although it is less common. In both cases, the PLC transaction stays local.
| Architecture | Polling location | WAN traffic | Expected behavior |
|---|---|---|---|
| Cloud gateway polls PLC directly | Cloud | Individual PLC protocol exchanges | Scan behavior follows WAN latency and interruptions |
| Local drivers with MQTT | Edge site | Published data | PLC polling remains independent of WAN round trips |
| Cloud-to-edge OPC UA | Edge site | OPC UA data exchange | Cloud reads the edge gateway rather than the PLC |
Check: Disconnect the WAN during a controlled test and confirm that local PLC polling continues; restore the link and verify that cloud data resumes through MQTT or the configured OPC UA connection.
How do you verify the complete commissioning path?
Test each boundary in the same order the packet crosses it. This separates physical, routing, encryption, authentication, application, and data-flow failures.
- At the edge site, verify local PLC communications and current values.
- Verify WAN reachability or VPN tunnel state.
- Confirm that only the intended public VPN or proxy listener is reachable.
- Inspect the TLS session and certificate identity where HTTPS/TLS is used.
- Attempt an edge connection with valid authentication, then verify that invalid authentication is rejected.
- Confirm that the cloud gateway receives data without directly polling the remote PLC.
- If Perspective is published, test an allowed project and verify that unrelated paths stay blocked.
- Review firewall and endpoint diagnostics for rejected traffic and unexpected listeners.
Check: Trace one known PLC value from the local driver, across the secured edge-to-cloud path, into the cloud gateway, and finally to the authorized Perspective view while public clear-text 8088 remains unreachable.
FAQ
Can I leave Ignition port 8088 open to the internet?
Do not expose the clear-text HTTP listener on 8088. Prefer a VPN; if public access is required, use HTTPS/TLS at a hardened endpoint and publish only the required service.
Does TLS make a public Ignition gateway as safe as a VPN?
No. TLS encrypts traffic and authenticates the configured endpoint, but the public application remains reachable and retains its attack surface. A VPN keeps the Ignition listener private and is the safer architecture.
Can I verify the secure path without polling a cloud PLC?
Yes. Confirm the PLC value at the local driver, verify its transfer through MQTT or the configured edge OPC UA path, and match the value and update behavior at the cloud gateway while public clear-text 8088 remains blocked.