Resolving Moxa NAT-102 ReconnectWait in Ignition Logix Driver

Check the NAT for a Stolen Gateway IP First

The Ignition device status sits at ReconnectWait. RSLinx on your desk PC browses the same CompactLogix through the same Moxa NAT-102 without trouble. Neither the Ignition logs nor the Moxa logs show anything useful.

Start here. Open the NAT-102 IP configuration and look for a secondary IP on the public side. In the confirmed case, the NAT had created a secondary IP that matched the Ignition gateway server's own address. Removing that entry brought the connection up right away.

The NAT translation itself was working. The driver settings were correct. The fault was an IP conflict.

Read the Symptoms Before Touching the Driver

Reference installation:

• PLC: 1769-L30ER, firmware v32.11
• NAT: Moxa NAT-102, firmware 1.00
• Private (PLC) network: 10.10.10.x. PLC at 10.10.10.5
• Public (shopfloor) network: 10.0.49.x. PLC translated to 10.0.49.128
• Ignition Allen-Bradley Logix Driver pointed at 10.0.49.128, all other settings default, port 44818
• Gateway and NAT on the same subnet and VLAN
• Other L3x PLCs behind units on the same network work fine with the same driver settings

The first row is the pattern to recognize. If one client works and another does not, and the driver config matches known-good units, stop editing the driver. That is not the fault.

Understand Why RSLinx Works and Ignition Does Not

RSLinx and the Logix Driver both open an EtherNet/IP session on TCP 44818. On the wire they look the same except for the source IP. So a failure that follows one client points at that client's address, not at the protocol.

Here is the traffic path:

1. The gateway sends a TCP SYN to 10.0.49.128:44818.
2. The NAT-102 rewrites the destination to 10.10.10.5 and forwards it to the PLC.
3. The PLC replies. The NAT rewrites the source back to 10.0.49.128 and must deliver the SYN-ACK to the gateway's IP on the public segment.

If the NAT also holds the gateway's IP as a secondary address, step 3 breaks. The NAT treats the reply as addressed to itself. It may also answer ARP for that IP, so the switch and other hosts send gateway-bound frames to the NAT's MAC. Either way the SYN-ACK never reaches the Ignition server.

The driver sees a connect timeout, drops to ReconnectWait, retries, and fails again in a loop. No session is ever established, so nothing application-level gets logged. The NAT also logs nothing, because it is not dropping the traffic as a firewall event. It is consuming it as its own.

Your desk PC is unaffected because the NAT never claimed its address.

Run the Diagnostic and Fix Sequence

Work in this order. The early steps take minutes and separate path problems from address problems.

1. Prove reachability from the gateway host itself, not your desk. Ping 10.0.49.128 from the Ignition server. Then test TCP 44818: on Windows use Test-NetConnection 10.0.49.128 -Port 44818, on Linux use nc -vz 10.0.49.128 44818. A failed or erratic result here while your desk PC succeeds confirms a source-specific fault.
2. Check ARP from a neighbour host. On another machine in 10.0.49.x, ping the Ignition server, then run arp -a. Compare the MAC listed for the gateway IP with the gateway's real NIC MAC. If it resolves to the Moxa's public-side MAC, you have found the conflict.
3. Check ARP on the gateway. Run arp -a on the Ignition server and confirm that 10.0.49.128 resolves to the NAT-102's public MAC. Also look for a duplicate-address warning in the server OS event log.
4. Inspect the NAT-102 IP settings. In the web console, list every IP assigned to the public interface: primary, secondary or alias, and any NAT or virtual IP entries. Any address other than the NAT's own IP and the intended translated IPs is suspect. An entry equal to the Ignition gateway IP is the fault.
5. Capture if steps 2-4 are inconclusive. Run Wireshark on the gateway with filter tcp.port == 44818. Outbound SYNs with no SYN-ACK back point to a diverted return path. A SYN followed by an RST points to a filter rule on the NAT.
6. Remove the rogue secondary IP. Delete the entry, then save and apply the NAT configuration.
7. Flush stale ARP. Run arp -d * (elevated) on the gateway and affected hosts, or wait for the ARP entries to age out. Clear the MAC table on the switch port if the switch holds the old binding.
8. Restart the device connection. Disable and re-enable the device in the Ignition gateway so it opens a fresh session rather than waiting out its retry timer.

Verify the Connection Holds

• Device status in Ignition changes from ReconnectWait to connected, and tags from the 1769-L30ER return good quality.
• arp -a on a neighbour host shows the gateway IP bound to the gateway's own NIC MAC.
• The port test to 10.0.49.128:44818 succeeds from the gateway host.
• RSLinx from the desk PC still connects. Both clients hold sessions at the same time.
• Power-cycle the NAT-102 and check the IP list again. If the secondary IP comes back after reboot, the fix did not stick and the unit is regenerating it.

Avoid the Fixes That Waste Time

• Tweaking Logix Driver settings. Default settings on port 44818 work for L3x controllers. Driver settings that match working installs rule out the driver.
• Entering the private IP in Ignition. The gateway lives on the public side, so it must target the translated address (10.0.49.128), never 10.10.10.5.
• Trusting "same subnet and VLAN." Sharing a subnet guarantees nothing if another device answers for your IP. Verify the MAC, not just the subnet.
• Hunting in the logs. An IP conflict produces no Ignition device errors beyond the retry state and no NAT firewall entries. Go to ARP and packet capture instead.
• Copying a NATR config line by line. Different NAT products manage public-side addresses differently. Audit the Moxa's full IP list on its own terms.
• Leaving addressing undocumented. Record every public IP the NAT owns, including the translated PLC addresses, in your IP plan, and exclude them from any DHCP scope. This prevents the reverse conflict, where a server takes an address the NAT already claims.
• Running the NAT on its initial firmware. The unit here ran 1.00. Check Moxa's download page for later NAT-102 firmware and its release notes before you commission more units.

Stop and escalate to Moxa technical support if the secondary IP reappears after deletion and reboot, or if you cannot find any setting that explains why it was created. Send them the configuration export, the firmware version, and your ARP and packet-capture evidence.

FAQ