1783-NATR setup: default IPs, DIP switches, and why the PLC behind it won't answer

Most calls I get about a 1783-NATR sound the same. The router pings, its web page opens, the rule is sitting right there in the table, and the controller behind it acts like it was never plugged in. Usually nobody set the gateway in the PLC. When it isn't that, it's the default addresses, a public port that stays dead on the bench, the wrong RSLinx driver, or an address somebody else on the plant network already owns. Below is the setup order I use, what each of those faults looks like, and what to check on the firmware before a used unit goes anywhere near a live network.

What the 1783-NATR actually does

One-to-one address translation between a machine network and a plant network. That's the whole job. Every device the plant needs to see gets one rule: its real address on the machine side, one public address on the plant side. A single 1783-NATR holds up to 32 rules.

Machine builders like it for exactly that reason. Ten identical machines can all run 192.168.1.x inside, the programs never change, and the plant still sees each PLC at an address of its own.

Three RJ45 ports. The public port is on the front, right under the status lights. Flip the unit over and you find the two private ports, Port 1 toward the front and Port 2 toward the back, sharing one IP address and one MAC. Run them linear, star or as a Device Level Ring. The public port has its own MAC and IP and is plain star Ethernet. DIP switches are on top, the SD slot is on the back, and the 24 V DC connector sits on the bottom behind the private ports.

Where everything sits on a 1783-NATR. Port 1 and Port 2 live underneath, away from the public port, and the serial number label you need for the first login is on the right side.

CIP, ping, HTTP and DNS go through without any extra setup, so RSLinx, ping tests and a device's own web page all work across it. Anything else that has to start from the plant side is different. Say a Modbus TCP master on the plant network polls a device behind the router on port 502. That port has to go in as a custom port on the mapping. You get up to five custom TCP or UDP ports per mapping, they're set from the web page only, and the feature needs firmware 1.002 or later. Traffic the machine starts itself goes out on any port without that.

First power-up: DIP switches and the default addresses

The router reads its DIP switches only at power-up. Move one while it's running and nothing changes, apart from a minor fault that stays until you move the switch back. Left is Off, right is On, looking at the unit from the front.

Switch 1	Switch 2	What the router does at power-up
Off	Off	Factory position. Private ports ask for an address over DHCP. Public port uses what is set in software, 169.254.1.1 from the factory
Off	On	Static. Uses the addresses saved in software. The factory static address for the private ports is 192.168.1.1
On	Off	Loads the stored settings, then suspends operation. OK light flashes red
On	On	Restores factory defaults, then suspends operation. Switch 3 is ignored

Switches 1 and 2 set the addressing. To get out of a suspended state, set the switches and cycle power.

Switch 3 is the ring supervisor switch. On, the router comes up as a supervisor; Off, software decides. On a linear or star network leave it Off.

Here's where the default address trips people up. 192.168.1.1 is the private default, sure, but only with switch 2 On. A new unit ships with all three switches Off, and in that position the private ports just sit there waiting for a DHCP server. The public port comes up at 169.254.1.1, mask 255.255.255.0, no gateway, and that address is meant for first setup only.

So before the first power-up I flip switch 2 On. The private side comes up at 192.168.1.1, the laptop goes on 192.168.1.2, and I'm in. You can also leave everything Off and hand it an address from the BOOTP/DHCP tool. If you go that way, hit Disable BOOTP/DHCP once the address takes, otherwise it's gone the next time the power cycles. It only works while no static address is saved, and a used unit might have one.

And don't run it on DHCP in production. This router is the gateway for the whole machine. If its address moves under a running process you can lose control of that process.

The setup order that works

Private side first, every time. The public port won't communicate at all until at least one private port is connected to a device that has an address. Try configuring it through the public port on a bench with nothing else plugged in and you'll swear the unit is dead.

1.    Switch 2 On, switches 1 and 3 Off. Power up. Laptop on Port 1 at 192.168.1.2, mask 255.255.255.0.

2.    Browse to 192.168.1.1, log in with admin and the serial number, set your own password.

3.    Set the private address. Pick one that no device on the machine uses, because it becomes the gateway for everything you translate.

4.    Set the public address, mask and gateway your plant network people gave you. Apply, then Reset Module under Device Services. Port changes don't take effect until that reset.

5.    On the Network Address Translation tab, make sure NAT Enable is set to Enabled, then add one rule per device. New Range builds a block of sequential rules if your addresses run in order. Rules work as soon as you add them, no reset.

6.    Set the gateway on every translated device to the router's private address. PLC, HMI, drives, I/O adapters, anything the plant has to reach.

7.    Save the configuration to the SD card.

8.    Test from the plant side, against the public addresses.

A complete set for one machine, with the same addresses as the drawing further down:

Device	IP address	Mask	Gateway	Public address in the rule
1783-NATR private ports	192.168.1.1	255.255.255.0	0.0.0.0	None
Router public port	10.20.30.50	255.255.255.0	10.20.30.1	None
PLC	192.168.1.10	255.255.255.0	192.168.1.1	10.20.30.60
HMI	192.168.1.11	255.255.255.0	192.168.1.1	10.20.30.61

One machine behind one router. From the plant, the PLC is 10.20.30.60 and the HMI is 10.20.30.61.

The last octets don't have to match between the two sides. People line them up to keep things readable, that's a habit and not a requirement. The hard rules are somewhere else: a public address in a rule can't be the router's own public port address, and a private one can't be its private port address.

Why the 1783-NATR answers and the PLC behind it doesn't

This is the big one. You ping 10.20.30.60 from a laptop at 10.20.30.100. The router translates the destination to 192.168.1.10 and the PLC gets the request just fine. But the source on that packet is still 10.20.30.100, which isn't on the PLC's subnet. So the PLC hands its reply to its gateway. If the gateway is blank, or still points at whatever address was on the machine builder's old drawings, the reply just dies. From the plant it looks like the rule is broken. The rule is fine.

Set the PLC gateway to 192.168.1.1, the router's private address, and it answers right away. On a Logix controller it lives in the same IP settings as the address itself.

Same rule, same ping. The only difference between the two panels is the gateway field in the PLC.

I check this before I even open the router's web page. Machine networks run for years with the gateway field blank, because nothing on them ever needed one. Then a NAT router shows up and suddenly every device does.

One catch, and there's no way around it. A device with no gateway setting at all has no way to send a reply to an address outside its own subnet, so it can't answer through the 1783-NATR. If something on the machine has no gateway field, it stays invisible from the plant.

When the gateway is right and it still won't talk

What you see	What it usually is	What to do
Public port dead: no ping, no web page	No private port connected to a device with an address	Plug the PLC or the laptop into Port 1 or Port 2
Pinging 192.168.1.x from the plant fails	Private addresses aren't reachable from outside, by design	Use the public address from the rule
RSLinx browse finds nothing behind the router	EtherNet/IP driver, which isn't supported on the public port	Ethernet devices driver with the public addresses typed in
Ping works, Modbus TCP from the plant won't connect	Port 502 isn't covered by the default mapping	Add 502 to that mapping's custom ports
New settings don't take	Port changes need a reset, DIP switches are read only at power-up	Reset Module, or cycle power
Intermittent drops, high error counts	Speed or duplex mismatch with the switch	Same settings on both ends; auto-negotiate is the default

Checks to run once the device gateway is confirmed.

Then there's duplicate addresses. The router's public port and every public address in your rules live on the plant subnet, and every single one of them has to be free. A rule address some laptop already grabbed can look a lot like a broken rule. When OK flashes red, go to Diagnostics and open Address Conflict Detection. It splits the check into the public interface, the private interface and the NAT rules, so you can see which address is fighting.

OK light	What it means	First check
Off	No 24 V DC power	Supply and the DC connector on the bottom
Green	Running normally	Nothing
Flashing red	Recoverable fault or duplicate IP address. A missing or dead SD card counts, and so does a suspend set by the DIP switches	Address Conflict Detection, the SD card, switch positions. It takes a reset to clear
Solid red	Unrecoverable fault	The hardware
Flashing red and yellow	The configuration could not be restored from the SD card	The card, and the firmware the backup was made on
Flashing red and green	Power-up self-test	Give it a moment

The OK light on the front, top of the column.

The other three lights are simpler. Green is a 100 Mbps link, yellow is 10 Mbps, flashing means traffic, off means nothing is moving on that port.

SD card backups and swapping a 1783-NATR

Leave the SD card in even if you never use it. That's one less reason for a red OK light.

After setup, write the configuration to the card from the web page. For a swap, power off, move the card into the replacement, restore from it on the web page, and check the public address and the rules before the public port goes back on the plant network.

Firmware matters here too. On 1.002 a configuration saved on an earlier revision wouldn't restore from the card, and 1.003 fixed that. Red and yellow flashing after a restore is the router telling you the restore didn't happen.

When it goes back on the rail, it goes on vertically. That's the only orientation it's built for. Give it an inch of clearance all around, and remember it grounds through the DIN rail, so it needs a proper zinc-plated steel rail.

On a line where every machine uses the same internal addressing, a spare is easy to keep ready. The private side is identical on all of them. Only the public side and the rule table change, and with the address table from the drawings that's a short job.

Firmware on a used 1783-NATR

Surplus routers come with whatever firmware they had when they left the last panel, and on this one it matters more than usual. Every version below 1.007 has known vulnerabilities. The worst is missing authentication on critical functions, scored 10.0 on CVSS 3.1. Someone who can reach the router could take over the admin account, change NAT rules or knock the router off the network, and getting the admin account back can take physical access to the unit.

Firmware	Released	What changed
1.002	May 2016	Custom TCP and UDP ports, up to five per mapping. Known issue: configurations saved on earlier firmware don't restore from the SD card
1.003	March 2017	SD card restore issue fixed
1.005	October 2020	Fixes for the VxWorks vulnerabilities
1.006	December 2021	Fixes for the GoAhead web server vulnerabilities
1.007	March 2025	VxWorks updates. Fixes CVE-2020-28895, CVE-2025-7328, CVE-2025-7329 and CVE-2025-7330

Firmware history of the 1783-NATR, Series A.

My rule for a used unit is simple. Check the revision before it touches a plant network. RSLinx device properties show it, same as for any other EtherNet/IP device. Below 1.007, flash it first. There is no workaround for those holes short of the update.

1783-NATR quick answers

What is the default IP address of a 1783-NATR?

It depends on switch 2. In the factory position, all switches Off, the private ports wait for DHCP and the public port is 169.254.1.1, mask 255.255.255.0, gateway 0.0.0.0. With switch 1 Off and switch 2 On, the private ports come up at 192.168.1.1, mask 255.255.255.0.

What is the default password on a 1783-NATR?

User name admin. The password is the serial number printed on the label on the right side of the router. You're asked to change it at the first login.

How do I factory reset a 1783-NATR?

There is no reset button. Power off, set switches 1 and 2 On, power up. The router restores factory defaults and suspends operation, and OK flashes red. Power off again, set the switches back to your running position, power up. Then reconfigure it or restore the saved configuration from the SD card.

How many devices can one 1783-NATR translate?

32, one rule per device. On firmware 1.002 and later each mapping can also carry as many as five extra TCP or UDP ports of its own. If more than 32 devices need plant access, you're looking at a second router, a 9300-ENA, which handles up to 128 devices, or a NAT-capable Stratix switch.

What power does a 1783-NATR need?

20.4 to 27.6 V DC, 150 mA, 3 W maximum, into the two-pin connector underneath. Operating range is -25 to 70 °C (-13 to 158 °F), and it's rated for Class I, Division 2 hazardous locations.

Replacing a dead 1783-NATR

Solid red on the OK light is an unrecoverable fault, and no setting clears it. When you hit it, we keep the 1783-NATR on the shelf as new surplus, covered by our 2-year warranty. New surplus still carries whatever firmware it left the factory with, so check it and take it to 1.007 before it goes on your plant network, same as any other unit.