Routing CJ1M ETN21 PLCs Through Internet with Overlapping WAN IPs

Problem Overview: WAN IP Overlap Blocking CJ1M ETN21 Remote Access

Remote programming of Omron CJ1M-CPU11/CPU12/CPU13 PLCs equipped with CJ1W-ETN21 Ethernet Units over the public internet depends on the engineering workstation being able to address the public IP address of the customer-premises router at the remote site. The operator runs CX-Programmer (or a SCADA package) on a Windows PC, opens a FINS/TCP connection through the office firewall, and arrives at the ETN21 on TCP port 9600 (the default FINS/TCP port for Omron Ethernet units).

When the DSL provider issues a public IP address to the remote site that falls inside the same IP range as the public IP address assigned to the office, the Windows TCP/IP stack refuses to send the packet through the default gateway. The remote address appears to the operating system to be a member of the office's own subnet. ICMP echo requests (ping) time out. TCP SYN packets to port 9600 never leave the office. Even when port forwarding on the remote DSL modem is verified and another site with a different WAN IP can be reached normally, the affected site remains unreachable from the office.

This symptom is independent of the Omron hardware. A second site whose WAN IP is in a different range is reachable using the same CX-Programmer project, the same PC, and the same firewall rules. The blocking condition is purely a host routing issue at the office PC: the destination address belongs to a subnet that the PC considers local, so the PC's default gateway is never consulted.

Three remediation paths exist:

1. Request a new address block from the ISP. In some regions this is impossible because the ISP owns the entire regional pool and the customer has no leverage.
2. Establish a VPN tunnel between the office and the remote site, encapsulating all traffic so that the inner addresses become private. The DSL modem at the remote site must support VPN pass-through or terminate the tunnel itself.
3. Insert a gateway PLC between the office and the affected PLC. The gateway PLC is installed at a third site whose WAN IP is in a different range from the office. A second CJ1W-ETN21 unit in the gateway PLC bridges the office-side FINS network to a second FINS network that terminates at the affected site.

This article documents option 3. The technique uses two ETN21 units in a single CJ1M CPU rack to bridge two independent FINS networks with a static FINS/TCP connection, exploiting the permanent TCP session that an ETN21 keeps open to a remote peer. The architecture is described in the CJ1W-ETN21 / CS1W-ETN21 Ethernet Units Construction of Applications Operation Manual (W421) and the CJ1W-ETN21 / CS1W-ETN21 Ethernet Units Construction of Networks Operation Manual (W420).

Affected Hardware, Firmware, and Tooling

Always verify the exact register layout, supported FINS/TCP connection count, and any firmware-specific behaviour against the manual shipped with the specific unit revision in service.

Root Cause Analysis: Why a Single ETN21 Cannot Bridge

When a FINS/TCP packet addressed to the target PLC arrives at the ETN21 in the gateway PLC, the ETN21 strips the FINS header and passes the inner FINS message up to the CJ1M CPU. The CPU evaluates the destination FINS address and decides where to forward the message. If the CPU's routing table maps the destination FINS network to a local communication port, the CPU hands the message to that port's ETN21 unit. That second ETN21 then re-encapsulates the message into a fresh FINS/TCP segment and forwards it to the remote peer.

On a single ETN21, however, the unit is the only network interface that owns the destination's FINS network. The ETN21 firmware, by design, will not loop a packet back out the same physical port. This is not a bug; it prevents packet storms and split-horizon problems when the FINS network is bridged to itself. The result is that a single ETN21 in a PLC is functionally a host on one FINS network, not a router between networks.

Installing a second ETN21 on a different FINS network gives the CPU two distinct interfaces. The CPU's routing table can then direct FINS traffic for the office-side network to ETN21 #1 and FINS traffic for the remote-site network to ETN21 #2. Each ETN21 only ever sees traffic on its own FINS network, so the loop-back restriction is never triggered.

It is also worth noting that the routing decision is performed by the CPU, not by either ETN21. The ETN21 is a special I/O unit that provides Ethernet connectivity; it does not implement FINS routing on its own. The CPU walks its routing table on every outgoing FINS message and selects the unit number to hand the message to.

Solution Architecture

The proposed architecture uses three PLCs across two FINS networks plus the office PC. The PC and PLC A are on FINS Network 1. PLC A and PLC B are on FINS Network 2.

1. PC running CX-Programmer — Office, WAN IP = A.B.C.D (problematic range, same /24 as PLC B's WAN).
2. PLC A (gateway) — Site 1, WAN IP = A.B.E.F (different range, reachable from office). Hosts two CJ1W-ETN21 units: ETN21 #1 on FINS Network 1 (LAN side toward office) and ETN21 #2 on FINS Network 2 (LAN side toward PLC B).
3. PLC B (target) — Site 2, WAN IP = A.B.C.X (same /24 as office, unreachable directly from office). Single CJ1W-ETN21 on FINS Network 2.

The DSL modem at Site 1 forwards TCP 9600 to ETN21 #1 in PLC A. The DSL modem at Site 2 forwards TCP 9600 to the ETN21 in PLC B. CX-Programmer on the office PC connects to ETN21 #1's WAN address. ETN21 #1 receives the FINS/TCP session, hands the FINS payload to the CJ1M CPU, and the CPU forwards it to ETN21 #2 because the destination FINS network 2 is registered in the CPU's routing table. ETN21 #2 maintains a permanent FINS/TCP connection to the WAN IP of Site 2 (PLC B's ETN21). The message arrives at PLC B's CPU, the response travels back along the same static TCP connection, and CX-Programmer on the office PC sees a normal local connection to PLC B.

Prerequisites

• PLC A must be a CJ1M (or CS1) rack with at least one free CJ-series special I/O slot for a second ETN21.
• CX-Programmer with a recent version capable of editing CPU routing tables, ETN21 IP router tables, and FINS/TCP connection lists.
• Outbound TCP 9600 from the office to Site 1 (PLC A's WAN IP).
• Outbound TCP 9600 from Site 1 to Site 2 (PLC B's WAN IP).
• Inbound TCP 9600 at Site 1 routed to ETN21 #1 in PLC A.
• Inbound TCP 9600 at Site 2 routed to the ETN21 in PLC B.
• Static or DHCP-reserved LAN IPs on each ETN21 so the DSL modems forward to the correct MAC every time the lease renews.
• Physical access to PLC A to install the second ETN21 and to assign its unit number via the rotary switch.

Step-by-Step Configuration

Step 1 — Assign LAN IP Addresses to the ETN21 Units

Connect a CX-Programmer-equipped PC to each ETN21 in turn and set the LAN-side IP, subnet mask, and FINS network number. The default IP of an ETN21 straight from the box is 192.168.250.1, FINS node 1. The default FINS network number is 1. Each ETN21 must be assigned a unique unit number between 0 and F (hex) on the CJ-series rack; the CPU uses the unit number to address the unit during FINS routing.

Recommended settings for the gateway architecture:

Keep the FINS node number unique across the entire bridged FINS network. Node 1 reserved for ETN21 #1 in PLC A, node 1 reserved for ETN21 #2 in PLC A (each on its own logical network), and node 10 for PLC B. CX-Programmer's auto-detection can collide on a multi-network PLC if two units report the same FINS node on different networks, so lock the node numbers explicitly.

Step 2 — Configure the IP Router Tables in Each ETN21

The IP router table tells the ETN21 which remote IP addresses are reachable through which default gateway. The IP router table is configured through CX-Programmer (or by writing the appropriate setup words in the I/O memory area allocated to the unit). The table has three columns: Remote IP Address, Subnet Mask, and Default Gateway IP. A single 0.0.0.0 / 0.0.0.0 entry acts as a default route and is the simplest configuration when the office IP is dynamic or one of several possible public addresses.

For PLC A — ETN21 #1 (office side, FINS network 1):

For PLC A — ETN21 #2 (remote side, FINS network 2):

For PLC B (target, FINS network 2):

See the W420 manual, page 3 for an example of an empty IP address table paired with a 0.0.0.0 mask in the IP router table. This combination is exactly the pattern that allows the office PC to use any of several possible public WAN IPs without needing to update the ETN21's IP address table on every ISP change.

Step 3 — Leave the IP Address Table Empty (or Wild-Card It)

The IP address table is the inverse of the IP router table. It maps remote FINS node numbers to remote IP addresses. When the table is left empty, the ETN21 uses the IP router table and the FINS source/destination IP embedded in the FINS header to route the response. This is the recommended configuration for the gateway PLC and for PLC B when the office has a dynamic public IP. If you need to lock down which FINS nodes are reachable, populate the table explicitly with the office WAN IP and the PLC A WAN IP.

The empty IP address table combined with a 0.0.0.0 / 0.0.0.0 IP router table is the configuration that makes the office's varying WAN IP transparent to the ETN21. Reference the same pattern shown in W420 page 3.

Step 4 — Configure FINS Network Routing in the CJ1M CPU

The CPU maintains its own routing table that maps FINS network numbers to local communication ports. On the CJ1M, open the PLC's routing table dialog in CX-Programmer and add two local network entries:

This tells the CJ1M CPU that FINS network 1 is reachable through ETN21 unit 0 and FINS network 2 is reachable through ETN21 unit 1. Without these entries the CPU has no way to know which special I/O unit owns which FINS network, and FINS messages for network 2 will be silently dropped. The routing table is stored in the CPU's parameter area; cycle power on the CJ1M after writing the table for the changes to take effect.

Step 5 — Open a Static FINS/TCP Connection from ETN21 #2 in PLC A to PLC B

The ETN21 supports up to eight simultaneous FINS/TCP connections. Configure one of them as a permanent client connection from ETN21 #2 in PLC A to the WAN IP of Site 2. In CX-Programmer, navigate to the ETN21 #2 unit setup, open the FINS/TCP tab, and add a connection with the following parameters:

The ETN21 will open a TCP session to the WAN IP of Site 2 and hold it open indefinitely. All FINS/TCP messages destined for FINS network 2 leave through this session. FINS responses from PLC B travel back along the same socket, eliminating the need for inbound port triggering on the Site 1 firewall. The static FINS/TCP connection between two ETN21 units is the mechanism recommended in the W420 manual for connecting through multiple segments such as the internet.

Step 6 — Configure Port Forwarding on the DSL Modems

On the DSL modem at Site 1, create a port-forwarding rule that maps inbound TCP 9600 to LAN address 192.168.10.10 (ETN21 #1 in PLC A).

On the DSL modem at Site 2, create a port-forwarding rule that maps inbound TCP 9600 to LAN address 192.168.30.10 (the ETN21 in PLC B).

If the DSL modems include a stateful firewall, allow outbound TCP from 192.168.20.10 to the Site 2 WAN IP on port 9600 so that the static client connection from ETN21 #2 in PLC A can be initiated. Without this outbound allow rule, the firewall will drop the SYN packet and the FINS/TCP connection will never establish.

Step 7 — Test the End-to-End Path

1. From a PC on the office LAN, ping the WAN IP of Site 1. The reply should arrive within a few tens of milliseconds.
2. From CX-Programmer, configure a new Ethernet connection to the WAN IP of Site 1, port 9600, FINS network 1, node 1. Click "Test Connection." CX-Programmer should connect to ETN21 #1 in PLC A.
3. Open the PLC A project and verify the CPU routing table contains both networks 1 and 2.
4. From CX-Programmer, change the connection target to FINS network 2, node 10. The FINS packet will be relayed through ETN21 #2 in PLC A and across the static FINS/TCP connection to PLC B.
5. On PLC B, the LINK LED on the ETN21 should be lit; the RUN LED should be solid green; the FINS/TCP COMM LED should pulse to indicate active traffic.

Verification Checklist

Troubleshooting Matrix

FINS/TCP Versus FINS/UDP — When to Use Each

The ETN21 supports both FINS/TCP and FINS/UDP on the same port number (9600 by default). FINS/TCP is a connection-oriented protocol that traverses NAT boundaries cleanly and survives short network outages by re-establishing the socket. FINS/UDP is connectionless and relies on IP broadcast or unicast. FINS/UDP is the correct choice for in-plant networks where ETN21 units sit on the same LAN and broadcast discovery is acceptable. FINS/UDP becomes unreliable across the internet because most DSL modems and firewalls block inbound UDP by default and UDP has no native NAT traversal mechanism.

The W420 manual recommends FINS/TCP for any communication that passes through multiple network segments, such as across the internet. The static client connection configured in Step 5 of this article is a FINS/TCP connection. The office PC's CX-Programmer connection to ETN21 #1 in PLC A is also a FINS/TCP connection (CX-Programmer initiates, ETN21 #1 accepts). Mixing FINS/UDP and FINS/TCP on the same PLC is supported but adds no benefit to the gateway architecture and is not recommended.

CPU Routing Table Reference

The CJ1M routing table contains three types of entries: local network entries (one per FINS network reachable through a local communication port), relay network entries (one per FINS network reachable through a remote gateway), and end network entries (one per FINS network that is the final destination of a relay). For the gateway architecture described here, only local network entries are required because every FINS network the CPU sees is owned by a unit on the same rack.

The routing table is stored in the CPU parameter area and is downloaded as part of the PLC project. After editing the table in CX-Programmer, transfer the project to the CPU and cycle power. Live edits to the routing table are not supported on the CJ1M. Refer to the W421 manual for the exact parameter area words and the supported number of routing table entries.

Alternate Approaches

If installing a second ETN21 in PLC A is impractical, the same gateway function can be implemented on an industrial router that supports FINS routing and FINS/TCP bridging. Omron's own industrial routers and many third-party industrial firewalls can be configured to act as FINS routers between two network segments. The benefit of using the PLC-based gateway is that no new hardware vendor is introduced and the field technician is working with familiar CX-Programmer dialogs.

Where the DSL modems at all sites support IPSec or WireGuard, a VPN mesh is the more robust long-term solution. The VPN removes the WAN IP overlap problem entirely because every endpoint is reached through a private tunnel. The cost is the administrative overhead of distributing VPN keys and maintaining the tunnel whenever the ISP changes a public IP. For a small number of sites (two or three), the gateway PLC architecture described in this article is the least intrusive fix.

Long-Term Hardening

Once the immediate reachability problem is resolved, schedule the following improvements to reduce the chance of recurrence:

• Replace the DSL modems with units that support IPSec or WireGuard, and roll out a hub-and-spoke VPN between the office and each site.
• Move all ETN21 FINS/TCP traffic onto a non-default port to reduce exposure to opportunistic internet scanning.
• Enable FINS/TCP client authentication and IP-filtering on the ETN21 to limit which remote FINS/TCP peers are accepted.
• Configure an SNMP trap destination on the ETN21 so that link-down events at remote sites are reported back to the office automatically.
• Document the IP router tables, IP address tables, and FINS/TCP connection settings in the site commissioning record so that future DSL provider changes can be absorbed without on-site intervention.
• Move the ETN21 off the default 192.168.x.x private range and onto a non-overlapping private range so that a future VPN rollout does not collide with the existing LAN addressing.

Field-Proven Caveats

The double-ETN21 gateway pattern is reliable but has three operational gotchas that surface only after deployment:

1. Single point of failure. If PLC A loses power, both ETN21 units drop and the office loses access to PLC B. Remote power-cycling of PLC A is not possible through the same path that just dropped. A watchdog timer or out-of-band management link to PLC A is recommended. A 3G/4G cellular router with a private APN is a low-cost way to keep a fallback path to PLC A without depending on the same DSL provider.
2. Static FINS/TCP session re-establishment. The connection from ETN21 #2 in PLC A to Site 2 is initiated by the client. If the Site 2 WAN IP changes (DHCP lease renewal by the DSL provider), the connection stays closed until ETN21 #2 retries. Most ETN21 firmware revisions retry every few minutes; verify the retry interval for the specific firmware in service. If the Site 2 WAN IP changes frequently, configure a dynamic DNS hostname on the Site 2 DSL modem and use the hostname in the ETN21's FINS/TCP client configuration rather than the raw IP.
3. FINS node number conflicts. If the office PC is on the same LAN as PLC A (for example, when commissioning on-site), the PC must be placed on FINS network 1 with a node number that does not collide with the gateway's ETN21 #1. CX-Programmer's auto-node detection works across the FINS/TCP bridge but is sensitive to duplicate node numbers on the same logical FINS network. Lock the office PC's FINS node to a value such as 100 to keep it out of the way of the PLC nodes.
4. ISP port blocking. Some consumer ISPs block inbound TCP 9600 (and other well-known industrial ports) at the CGNAT level. Confirm with the ISP that the assigned public IP is a true routed address and not a CGNAT address behind the ISP's carrier-grade NAT. CGNAT is invisible to the customer and presents as a normal public IP from inside the customer's LAN, but incoming connections are dropped at the ISP's NAT.

Frequently Asked Questions