How to Connect to a Niagara JACE Remotely

Why Remote JACE Access Is Difficult

A JACE controller is a headless embedded device that sits on a building's OT (operational technology) network. Unlike IT servers that are designed for remote management from day one, JACEs are typically commissioned on-site over a direct Ethernet connection and never touched again until something breaks. The network path between your laptop and a remote JACE usually crosses at least one NAT boundary, one or more firewalls, and possibly a VPN concentrator—none of which are configured for Fox protocol traffic by default.

Niagara uses the Fox protocol for Workbench-to-station communication. Fox runs on TCP port 4911 in Niagara 4.x and later, or TCP port 5011 on Niagara AX (3.x). This is a proprietary binary protocol, not HTTP, so standard reverse proxy setups and web application firewalls do not work with it. The JACE also serves its web UI over HTTPS (TCP 443), which is easier to proxy but still requires valid TLS certificates to avoid browser and Workbench warnings.

On top of the networking challenges, Niagara's built-in TLS certificates are self-signed and bound to the controller's IP address or hostname at commissioning time. When you access the JACE through a different IP (the public NAT address, a VPN address, or a DNS name), the certificate doesn't match, and Workbench may refuse to connect or throw errors that look like authentication failures.

Method 1: Port Forwarding

Port forwarding is the simplest approach and requires no additional software on the JACE. You configure the site's firewall or router to forward inbound traffic on specific ports to the JACE's internal IP address.

Steps

1. Assign the JACE a static IP address on the building network. DHCP-assigned addresses will break port forwarding rules when the lease renews.
2. Log into the site's firewall or router and create port forwarding rules for:
   • TCP 443 (HTTPS web UI) → JACE internal IP, port 443
   • TCP 4911 (Fox protocol, Niagara 4.x) → JACE internal IP, port 4911
3. If the site has a dynamic public IP, set up a dynamic DNS (DDNS) service so you can reach the site by hostname instead of IP.
4. Open Workbench and connect using the site's public IP (or DDNS hostname) on the default Fox port.

Security Concerns

Port forwarding exposes the JACE directly to the internet. Anyone who discovers the public IP and port can attempt to authenticate. Niagara does enforce username/password authentication and TLS on the Fox channel, but the attack surface is significant:

• Brute-force login attempts against the JACE's local user database
• Exploitation of any unpatched Niagara vulnerabilities (CVEs have been published for older Niagara versions)
• Denial-of-service by flooding the Fox port, which can crash or slow the controller

Port forwarding is acceptable for temporary access during commissioning but should not be left in place as a permanent remote access method. If you must use it long-term, restrict the source IP range in the firewall rule to your office's public IP, and keep the JACE firmware current.

Method 2: VPN Access

A VPN tunnel is the standard approach for ongoing remote JACE access in production buildings. The VPN places your workstation on the same logical network as the JACE, so you connect to the controller's internal IP exactly as if you were on-site. No port forwarding rules are needed, and the JACE is not exposed to the public internet.

Common VPN Configurations

The VPN type depends on what hardware is already at the site and what your organization supports. The most common setups in building automation are:

• Site-to-site IPsec VPN. The building's firewall establishes a persistent IPsec tunnel to your company's headquarters or data center firewall. All traffic between the two networks flows through the tunnel automatically. This is the most transparent option—Workbench connects to the JACE's internal IP without any special client configuration. However, it requires coordination with the building's IT team and your own network team to set up matching IPsec parameters (IKE version, encryption algorithm, pre-shared key or certificates, and Phase 2 selectors).
• Client VPN (SSL/TLS-based). You install a VPN client on your workstation (OpenVPN, Cisco AnyConnect, Palo Alto GlobalProtect, or similar) and connect to the site's VPN concentrator. The concentrator assigns your workstation an IP on the building network or a routable overlay network. This method works well for technicians who need access to multiple sites—each site gets a VPN profile, and you connect to whichever site you need. The downside is that every technician needs VPN credentials for every site, which creates a credential management burden.
• Cellular router with built-in VPN. Many BAS integrators deploy a small cellular router (Cradlepoint, Digi, Sierra Wireless) at each site specifically for remote access. These routers include an LTE/5G modem and a VPN client that connects back to the integrator's central VPN server. The JACE connects to the cellular router's LAN port or sits on the same VLAN. This approach is completely independent of the building's IT infrastructure, which avoids the political and technical overhead of getting VPN access through a customer's firewall.

VPN Setup Tips for JACE Access

• Make sure the VPN assigns your workstation a route to the JACE's subnet. Split-tunnel VPNs sometimes exclude the OT VLAN from the routing table.
• If the JACE is on a separate VLAN from the VPN endpoint, confirm that inter-VLAN routing is enabled and no ACLs block TCP 4911 or TCP 443 between VLANs.
• Test both the web UI (HTTPS) and Workbench (Fox protocol) after establishing the VPN. It is common for HTTPS to work while Fox is blocked by a stateful firewall rule that only permits ports 80 and 443.

Method 3: Niagara Cloud Connector

Tridium offers a cloud-based remote access service through the Niagara Cloud Connector module. The JACE initiates an outbound connection to Tridium's cloud relay servers, which means no inbound firewall rules or VPN tunnels are required at the site. Technicians log into the Niagara Cloud web portal and access the JACE's web UI or open a Workbench session through the cloud relay.

This approach works well for sites where IT will not open any inbound ports and there is no existing VPN infrastructure. The JACE only needs outbound HTTPS access (TCP 443) to Tridium's servers, which most corporate firewalls already permit.

There are trade-offs to be aware of:

• Licensing cost. Niagara Cloud Connector requires a per-station subscription from Tridium or your distributor.
• Niagara version requirements. The Cloud Connector module requires Niagara 4.4 or later. Older JACE firmware must be upgraded before the module can be installed.
• Latency. All traffic routes through Tridium's cloud relay, so Workbench operations (especially large station transfers or database downloads) will be slower than a direct VPN connection.
• Dependency on Tridium's infrastructure. If the cloud relay service is down, you lose remote access to all connected JACEs until service is restored.

Fixing Common JACE Remote Access Errors

Certificate Errors in Workbench

The most frequent remote access error is a TLS certificate mismatch. The JACE's self-signed certificate is typically issued to the controller's internal IP address (e.g., 192.168.1.100). When you connect through a VPN using a different IP, or through port forwarding using the site's public IP, the certificate's Subject Alternative Name (SAN) does not match the address you typed in Workbench.

To fix this:

1. Connect to the JACE locally (or via any working connection).
2. In Workbench, navigate to Platform > Platform Administration > Platform Services > CertManagerService.
3. Regenerate the server certificate. Add the JACE's internal IP, VPN IP, public NAT IP, and any DNS hostnames as Subject Alternative Names.
4. Restart the platform daemon when prompted.

If you cannot regenerate the certificate, you can work around the error by adding the JACE's certificate to your Workbench trust store. In Workbench, go to Tools > Options > Certificate Management and import the JACE's certificate as a trusted certificate. This suppresses the mismatch warning but does not fix the underlying issue.

Fox Protocol Connection Refused or Timeout

If Workbench says "Connection refused" on the Fox port, check these items in order:

1. Port reachability. From your workstation, run telnet <jace-ip> 4911 (or Test-NetConnection -ComputerName <jace-ip> -Port 4911 in PowerShell). If the connection is refused or times out, the issue is network-level, not Niagara-level.
2. Fox service running. The Fox service can be disabled in the JACE's platform configuration. Check Platform > Platform Services > FoxService and confirm it is enabled and bound to the correct network interface.
3. Firewall rules. Both the site's perimeter firewall and any host-based firewall on the JACE's OS must allow TCP 4911 inbound. On JACE 8000 controllers running QNX, there is no host firewall by default. On Niagara Supervisor instances running on Windows, check Windows Defender Firewall.
4. Port mismatch. Confirm you are using the correct Fox port for the Niagara version. Niagara 4.x uses TCP 4911 by default. Niagara AX (3.x) uses TCP 5011. If the station has been configured with a non-default port, check the FoxService properties for the actual bound port.

Port Conflicts

If you are running a Niagara Supervisor on a Windows server that also hosts other applications, port 443 or port 4911 may already be in use. Niagara will fail to start its web server or Fox service if the port is occupied. Check for conflicts with netstat -ano | findstr 4911 and either change the conflicting application's port or reconfigure the Niagara station to use an alternate port.

Niagara Workbench Remote Connection Steps

Once you have network reachability to the JACE (via VPN, port forward, or cloud connector), follow these steps to connect with Workbench:

1. Open Niagara Workbench on your local machine.
2. Click File > Open > Open Station (or use the Open Station button on the toolbar).
3. In the Host field, enter the JACE's IP address or hostname. This is the internal IP if you are on a VPN, the public IP if using port forwarding, or the cloud relay address if using Niagara Cloud.
4. Set the Port to 4911 (Niagara 4.x default). Change this only if the station uses a non-standard Fox port.
5. Enter your Niagara username and password. These are the credentials configured on the JACE's UserService, not Windows or VPN credentials.
6. If you receive a certificate warning, review the certificate details. If the issuer matches the JACE's self-signed certificate (the Common Name will typically say "Niagara4" or the station name), accept it and optionally add it to your trust store.
7. Click OK. Workbench opens the station's Nav tree. You now have full engineering access.

To access the JACE's web UI instead of Workbench, open a browser and navigate to https://<jace-ip>/. Accept the certificate warning if prompted. The web UI provides a limited view compared to Workbench but is useful for quick checks, alarm acknowledgment, and viewing graphics without installing Workbench.

Common Niagara JACE Remote Access Mistakes

• Forwarding only port 443 and forgetting port 4911. The web UI will load in a browser, but Workbench will fail to connect because Fox protocol traffic on TCP 4911 is not being forwarded. You need both ports for full remote functionality.
• Using the wrong Fox port for the Niagara version. Niagara 4.x defaults to TCP 4911. Niagara AX defaults to TCP 5011. Connecting to the wrong port produces a "Connection refused" error that looks identical to a firewall block.
• Ignoring certificate SAN mismatches. Accepting the certificate warning once does not permanently fix the problem on all machines. Every technician's Workbench instance will encounter the same warning until the JACE's certificate is regenerated with the correct SANs, or each Workbench trust store is manually updated.
• VPN split-tunnel excluding the OT VLAN. Your VPN connection may route traffic to the building's IT subnet (e.g., 10.1.1.0/24) but not to the OT VLAN where the JACE lives (e.g., 10.1.50.0/24). Check your VPN client's routing table with route print (Windows) or netstat -rn (macOS/Linux) to verify a route exists to the JACE's subnet.
• Workbench version mismatch. Workbench must match the JACE's Niagara version within the same major release. A Workbench 4.10 client cannot open a station running Niagara 4.13—the connection will fail with a version compatibility error. Keep Workbench updated to match your deployed JACE firmware versions, or maintain multiple Workbench installations for different versions.

Platform and Version Compatibility

Remote access capabilities vary slightly across JACE hardware and Niagara software versions. Here is what to expect:

When planning remote access for a fleet of JACEs, standardize on a single Niagara version across all controllers where possible. Mixed versions create Workbench compatibility headaches and make it harder to maintain consistent security policies. At a minimum, keep all controllers within the same Niagara major version (e.g., all on 4.x) and within two minor versions of each other.

Source Attribution

This guide draws on technical documentation and community discussion from the following sources:

• HVAC-Talk Forums — Technician discussions on JACE remote access, VPN configurations, and Fox protocol troubleshooting
• Tridium — Niagara Framework Product Documentation and Networking Guides
• OneSight Knowledge Base — Remote BAS Access Best Practices
• Tridium Technical Bulletins — Fox Protocol Configuration, Certificate Management, and Cloud Connector Setup