Configuring CJ1M-ETN21 and NS8 HMI Remote Access over WAN

Configuring CJ1M-ETN21 and NS8 HMI Remote Access over WAN

Programming an Omron CJ1M PLC and an NS-series HMI from across the public Internet is one of the most common service-engineering tasks in machine automation, and it is also one of the most common sources of late-night support calls. The combination of a CJ1M-CPU12 with a CJ1W-ETN21 Ethernet unit and an NS8-TV01B-V2 HMI is robust on the LAN but exposes two fundamentally different remote-access behaviors: the ETN21 was specifically designed to remember remote FINS nodes, while the NS HMI was not. This article walks through the complete commissioning procedure for both devices, including FINS/UDP port 9600 forwarding, default-gateway programming, routing-table entries, and the VPN-based workarounds required when the operator's home IP changes nightly.

1. Overview

The two devices involved communicate using Omron's FINS (Factory Interface Network Service) protocol over UDP. By factory default, FINS uses UDP port 9600 for both command and response traffic. The ETN21 unit adds FINS-to-IP address translation and supports a feature called Auto Dynamic (AUTO:DYNAMIC) routing, which lets the PLC remember the IP address of every remote node it has recently spoken to. The NS HMI, on the other hand, behaves like the older ETN11 unit: it cannot resolve a return path to a remote computer automatically, so the destination IP must be programmed into the HMI project before the connection is attempted.

Two practical paths exist for remote access:

1. Port forwarding on the plant router: Direct incoming TCP/UDP on a public port to the PLC or HMI's private LAN address. Suitable when the remote operator has a static IP or a stable dynamic DNS hostname.
2. VPN termination on the plant router: The remote operator joins the plant LAN as if physically present. Avoids every FINS routing pitfall but requires a router that supports VPN pass-through or termination.

2. Prerequisites

Before configuration, confirm that the following hardware, software, and information are available.

3. CJ1W-ETN21 Remote Configuration

The CJ1W-ETN21 is the easy half of the job because it implements AUTO:DYNAMIC routing. Once UDP 9600 is forwarded by the plant router and the default gateway is set on the unit, CX-Programmer can reach the PLC from any remote IP without further table entries.

3.1 IP Address and Default Gateway

Open CX-Programmer and connect to the ETN21 with a USB or Ethernet cable. Expand IO Table > Built-in Port / Ethernet and double-click the ETN21. In the TCP/IP and Link tabs, program the following:

Transfer the new settings to the PLC and cycle power to the ETN21 only (do not power-cycle the entire rack or you will lose the rest of the I/O mapping).

3.2 AUTO:DYNAMIC Routing Mode

In the ETN21's FINS/UDP setup screen, set Routing Table Method to AUTO (DYNAMIC). This is the default, but the user must verify it because the older ETN11 forced AUTO (STATIC) only. With AUTO:DYNAMIC, when the PLC receives a FINS frame from an unknown remote IP, it automatically adds that IP to its internal conversion table for the lifetime of the unit. The next time you connect from the same home IP, the route already exists.

3.3 Plant Router Port Forward

Forward UDP 9600 (default FINS) to the ETN21's LAN IP. The rule on a typical Linksys-style consumer router is:

If the router uses a non-default external port (e.g. 49600) and NATs to internal 9600, configure the same external-port number in CX-Programmer's Network > Connect via Hub dialog so the FINS node table in CX-Programmer matches the public listener.

3.4 CX-Programmer Remote Connection

From the remote PC, run CX-Programmer. Choose File > New with the PLC type set to CJ1M, then choose PLC > Auto Online > Ethernet. Type the plant's public IP or DDNS hostname and click Search. CX-Programmer sends a FINS command packet to UDP 9600; the ETN21 receives it, learns the remote IP into its conversion table, and replies. The PLC appears in the online list and the project transfers normally.

4. NS8 HMI Remote Configuration

The NS8-TV01B-V2 is the harder half of the job. The NS series implements a subset of the FINS stack that does not include AUTO:DYNAMIC conversion. The HMI cannot learn the remote IP on its own, and it cannot respond to a FINS command that arrived from an IP it has never seen.

4.1 Why Port-Forwarding Alone Is Not Enough

When the operator at home opens CX-Designer and connects to the NS's public IP on its HTTP port, the request reaches the NS, but the NS has no entry in its destination table for the home IP. The NS receives the screen-transfer request on its HTTP server (default TCP 80), but for any subsequent FINS-level commands (read/write tags, transfer project) the NS must know which IP to send replies to. Because the HMI's routing table is only AUTO:STATIC, those replies never reach the operator.

4.2 Programming the Remote IP into the NS

If the operator's home IP is static, the workaround is straightforward:

1. Open the NS project in CX-Designer on the plant PC.
2. Select PT - Network Settings and click the FINS tab.
3. Set Network Address (IP) to the operator's public IP address (e.g. 203.0.113.45).
4. Set the Subnet Mask and FINS Node Number for the remote side.
5. Transfer the project via CF card or the existing LAN.

The HMI now knows how to reply to that one specific remote IP. If the operator later changes location, the project must be updated and reloaded by a technician on site. This is the reason the NS manual recommends ports above 49152 - they keep the dynamic port range on the HMI side free of operator conflicts - but it does not solve the routing limitation by itself.

4.3 Practical Limits of the IP-Programming Workaround

• The home operator must have a static public IP from their ISP, or DDNS that resolves to the same IP for the life of the project.
• If the ISP hands out a new IP after a router reboot (common with CGNAT), the HMI will not respond until someone reloads the project.
• Multiple remote operators (office engineer, OEM support, second-shift maintenance) require multiple programmed IP entries or a separate VPN.

5. ETN21 vs ETN11 vs NS Routing Behavior

The clean engineering conclusion is that the ETN21 was specifically built to solve the "remote programmer on a changing IP" problem, while the NS HMI was not. When a plant has several NS panels and one or more PLCs, the standard support topology in the field is to use one PLC with two ETN21 cards: one on the WAN-facing router segment, the other on the local machine network with all NS panels. All remote programming traffic (PLC and HMI) flows through the WAN-side ETN21, which converts the FINS node numbers to the appropriate machine IP.

6. VPN-Based Workaround

The simplest long-term solution for remote programming of both the CJ1M and the NS is a VPN that gives the remote PC a routable address on the plant LAN. Once the VPN tunnel is up, neither FINS routing nor port forwarding needs to be reconfigured for changes in the operator's home IP.

6.1 VPN Options

• Plant router with built-in VPN: Many industrial routers (and most consumer routers after DD-WRT/OpenWrt) support IPsec or OpenVPN. The VPN terminates on the router, putting the remote PC on the plant subnet.
• Windows built-in VPN client: Suitable for built-in protocols such as PPTP or L2TP/IPsec. Performance is adequate for CX-Programmer and CX-Designer traffic, which is low-bandwidth.
• Third-party VPN client: OpenVPN GUI, WireGuard, GlobalProtect, or similar. Required when the plant router supports modern protocols.

6.2 Subnet-Mismatch Pitfall

The most common VPN failure is that the VPN hands out addresses on a different subnet than the PLC. For example, the plant LAN is 192.168.1.0/24 with the PLC at 192.168.1.50, but the VPN pool is 192.168.5.0/24. The remote PC can ping the VPN gateway but cannot reach the PLC because the gateway does not bridge the two pools. Verify in the router's VPN settings that the VPN tunnel's pool is either the same subnet as the plant LAN or that the PLC's default gateway has a static route to the VPN pool.

6.3 Remote-Desktop Approach

If the plant already has a Windows PC on the LAN (a SCADA node, an engineering station), the simplest secure configuration is:

1. VPN or RDP into the engineering station on the plant LAN.
2. From that station, run CX-Programmer and CX-Designer locally against the PLC and HMI.

This bypasses all FINS routing questions because the traffic stays inside the plant LAN. Microsoft's built-in Remote Desktop Connection handles this well, and Chrome Remote Desktop offers a quick no-VPN alternative if the plant PC has Chrome installed and a Google account signed in. Both options put the operator on the same subnet as the PLC from the device's point of view.

7. Step-by-Step Commissioning Procedure

1. Confirm LAN functionality first. From the plant PC, open CX-Programmer and confirm an online connection to 192.168.1.50 (UDP 9600). Confirm CX-Designer connects to the NS at 192.168.1.60 (TCP 80) and that a small test screen transfers cleanly. Do not proceed until LAN-only communication works in both tools.
2. Set the ETN21 default gateway to the LAN-side IP of the plant router (typically 192.168.1.1).
3. Verify AUTO:DYNAMIC is selected in the ETN21's routing table method.
4. Confirm a static public IP or DDNS hostname on the plant router. Write it down.
5. Forward UDP 9600 to 192.168.1.50 on the plant router. Both directions (UDP is two-way); no special NAT loopback rules are needed unless the same plant PC must also reach the PLC externally.
6. Forward TCP 80 (or the configured NS port) to 192.168.1.60 for NS screen transfer.
7. From home, test the PLC first. Open CX-Programmer, enter the public IP, attempt Auto Online. If the PLC appears, AUTO:DYNAMIC has populated the route.
8. For the NS, choose one of:
   • Program the home public IP into the NS project and re-transfer the project, or
   • Establish a VPN to the plant router and treat the NS as if it were on the LAN.
9. Verify each leg using the procedure in section 8.

8. Verification

After every configuration change, run the following matrix before declaring the system operational.

9. Troubleshooting Matrix

10. Field-Engineering Notes

• Always test LAN before WAN. Every WAN-only failure I have seen in the field turned out to be a misconfigured LAN parameter that the LAN test would have caught.
• Document the public IP or DDNS hostname in the customer site file. Operators rotate, and the next engineer will not have the URL handy.
• Prefer VPN over port forwarding if the plant IT department is willing. Port forwarding exposes UDP 9600 to the entire public Internet, which is a security exposure even if the PLC behind it is read-only.
• Use a CF card to reload NS projects on site. Omron supports CF-based screen transfer specifically because remote NS programming through an ETN11-style serial fallback is unreliable. Even on a healthy VPN it can take an hour for a medium-sized project.
• When in doubt, run an industrial 4G/LTE router with its own VPN at the customer site. It eliminates the customer's IT approval cycle and is the de facto standard for OEMs doing remote service today.

FAQ