DST-NAT for multiple wan addresses

chaosinc · Tue Apr 15, 2025 10:25 pm

Hello. I have searched the forum, applied what I found but I still find myself unable to finish my task, so I have turned to forums.
I went through mainly these existing threads and guides:
viewtopic.php?p=1138153&hilit=dstnat#p1138153
viewtopic.php?t=215953
viewtopic.php?t=186656

My difference from the existing threads (and yes, I am also in industrial automation world) is, that I am not trying to achieve same LAN device IPs to separate WAN IPs (as in "you have 4 PLCs with same IP, give them 4 different WAN addresses, so the other servers can address them as such"), but I am trying to make two specific IPs from LAN visible on two WAN IPs. They might be on ether2 both (another simple switch in my machine), or ether2 and ether3.

Seems similar enough, I also read that this should be doable with just a DST-NAT rule and nothing else, but I keep failing.

I set up a test network before i go poke into production as follows:
TPlink main router 10.0.80.1/24
LAN1->mikrotik hex WAN

Mikrotik hex:
WAN - 10.0.80.200, 10.0.80.201, 10.0.80.202
LAN - 192.168.250.51/24

Client device:
TPlink router with admin access from WAN enabled
WAN IP 192.168.250.1
WAN connected to LAN of mikrotik hex.

Second client device will have WAN IP 192.168.250.100, but at this moment I do not care, I first want to see the first one working.

After trying many things I have decided to reset the configuration and start with minimal changes, those being extra WAN addresses, just in case disabling the firewall rule of "drop all not coming from LAN" and adding one dst-nat rule.

If I connect to 10.0.80.0/24 network, i can ping:
10.0.80.200, 10.0.80.201, 10.0.80.202
I have RouterOS interface on 10.0.80.200 and 10.0.80.202
This does seem to make sense, since I applied dst-nat on 10.0.80.201, so everything should flow to my client device.

However, no tplink admin screen visible on 10.0.80.201

I made a test by placing an oscilloscope in the network as a client with 192.168.250.40. Adjust the dst-nat rule and could talk to it at 10.0.80.201:3000, so that seemed to be working, at least partially.
Tomorrow I want to make a test with actual production machine, where the clients will be PLC and HMI at 192.168.250.1 and 192.168.250.100. If I can talk to those, it is obviously the TPlink being special, but I might be missing something else.

Could you point me towards the light please? Thanks

/interface bridge
add admin-mac=############ auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip dhcp-server
add disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
/ip firewall connection tracking
set enabled=yes
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.250.51/24 comment=defconf interface=bridge network=192.168.250.0
add address=10.0.80.200/24 comment="wan primary ip" interface=ether1 network=10.0.80.0
add address=10.0.80.201/24 interface=ether1 network=10.0.80.0
add address=10.0.80.202/24 interface=ether1 network=10.0.80.0
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.250.51 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.0.80.201 log=yes protocol=tcp to-addresses=192.168.250.1
add action=src-nat chain=srcnat disabled=yes out-interface=ether1 src-address=192.168.250.1 to-addresses=10.0.80.201
/ip route
add disabled=yes distance=1 gateway=10.0.80.1
/system clock
set time-zone-name=Europe/Belgrade
/system identity
set name=RouterOS
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

McGremlin · Wed Apr 16, 2025 12:32 pm

Hello.

TP-LINK can be special - you can try to reach it by port 80 (HTTP), it automaticly transfers it to port 443 (HTTPS) because of it's configuration and you cannot reach it. DST-NAT rule like yours works only when ports are the same on both sides (80 -> 80, 443 -> 443, etc.). If you connect "real" clients it should work.

I made a test by placing an oscilloscope in the network as a client with 192.168.250.40. Adjust the dst-nat rule and could talk to it at 10.0.80.201:3000, so that seemed to be working, at least partially.

Why only partially? What do you mean?
And why are you using DST-NAT and not "normal" communication with static route on main router?

On Mikrotik get rid of DHCP server, you don't use it - or change it to proper addressing if you plan to use it.

Larsa · Wed Apr 16, 2025 2:31 pm

Hello @chaosinc and welcome to the forum!

The issue is likely that your TP-link doesn't send return traffic back through the Mikrotik, probably because it lacks a proper default gateway or a route back to it. If you can't fix it, you'll need to use src-nat or masquerade on the outbound traffic from the Mikrotik.

I noticed you already have a src-nat rule in your currently config, but it's disabled:
"add action=src-nat chain=srcnat disabled=yes out-interface=ether1 src-address=192.168.250.1 to-addresses=10.0.80.201"

You can either enable that one, or use a more general like this using masquerade:
"/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1"

To trace NAT translations and verify the traffic path, you can enable logging on your NAT rules and use the built-in packet sniffer tool (/tool sniffer).

chaosinc · Wed Apr 16, 2025 3:30 pm

...
TP-LINK can be special - you can try to reach it by port 80 (HTTP), it automaticly transfers it to port 443 (HTTPS) because of it's configuration and you cannot reach it. DST-NAT rule like yours works only when ports are the same on both sides (80 -> 80, 443 -> 443, etc.). If you connect "real" clients it should work.

Ahhh ok that might explain many things. I lack an extra PLC to play with or a raspi or another laptop with full control over it at this moment, so I used that as a cheap client, and obviously failed miserably, nice.

Why only partially? What do you mean?

Partially, because this scope does not have a webserver, it just has some sort of listener on port 3000 and then you can connect management app and check current status of screen. It seems to work and it stop working when i pull ethernet from scope, so there is that. Likely works ok, but with this limited way of testing I can't say for sure.

And why are you using DST-NAT and not "normal" communication with static route on main router?

Mainly, because when this is fully up and running, i will have likely 10-20 Mikrotiks, each with 3 WAN IPs (router, PLC, HMI), all in 10.0.80.0/24 network. And on each LAN of those Mikrotiks will be the actual PLC and HMI devices, which on half of them are sitting at 192.168.250.1 and 192.168.250.100, other half is semi-randomly placed in 192.168.xxx.xxx land.

I ultimately want to achieve two things (and very likely the same things that other automation people visiting this forum are trying to achieve).

1 - translate the 2nd and 3rd WAN IP to PLC and HMI, respectively, so I can access them directly from a server sitting at 10.0.80.100, which will use NodeRED to read out running data. Mainly to prevent IP conflicts.
2 - use this directly assigned WAN addresses to be able to program all machines from my workstation, without using VPN to the router

1 - seems possible without many issues
2 - I shot myself into foot, because very often the less developed devices do not allow to set a PLC/HMI address for the device, but contact it via different IP address. Meaning, that if I am in Mikrotik LAN with laptop at 192.168.250.50 and trying to program PLC at 192.168.250.1, all is well. However, if I move the laptop to 10.0.80.101 and access via mikrotik WAN 10.0.80.201, I can't connect to it without setting the target PLC address in programming software to 10.0.80.201, which will then set the ETH port on PLC to this IP on first transfer to PLC, and machine will promptly cease function. So here the proper solution would be to have Mikrotik act as OpenVPN server and each time I want to change code, VPN into local subnet of specific machine.

chaosinc · Wed Apr 16, 2025 3:42 pm

Hello @chaosinc and welcome to the forum!

The issue is likely that your TP-link doesn't send return traffic back through the Mikrotik, probably because it lacks a proper default gateway or a route back to it. If you can't fix it, you'll need to use src-nat or masquerade on the outbound traffic from the Mikrotik.

I noticed you already have a src-nat rule in your currently config, but it's disabled:
"add action=src-nat chain=srcnat disabled=yes out-interface=ether1 src-address=192.168.250.1 to-addresses=10.0.80.201"

You can either enable that one, or use a more general like this using masquerade:
"/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1"

To trace NAT translations and verify the traffic path, you can enable logging on your NAT rules and use the built-in packet sniffer tool (/tool sniffer).

Aha, thanks. Yes on some devices I can not access the gateway settings. This is why one user likely suggested to add address 192.168.250.51 (mikrotik LAN address) to ether2-5 ports, whichin my case should be assigned to bridge sitting on ether2-5, plus src-nat after that.

I also read that unless the device in the LAN tries to start comms, it is ok just to have dst-nat, since all prompts will come from WAN. No idea whether this is right or not.
I have now also enabled the src-nat, which should work on 192.168.250.1 -> 10.0.80.201

I can see in packet sniffer that ping on 10.0.80.201 arrives from my laptop, but it seems icmp is not affected by dst-nat, so it is likely mikrotik itself responding.

I will try to get hold of something which can act as a small webserver to make absolutely sure all issues are on my side (first TPlink being special, then PLC programming suite actually requiring correct local IP, etc etc)

I presume the packet sniffer tool should see the oscilloscope comms at port 3000, since that is tcp. I shall try that asap.

Larsa · Wed Apr 16, 2025 4:10 pm

dst-nat only changes the destination address, so when a packet from your laptop (say 10.0.80.50) hits 10.0.80.201, Mikrotik forwards it to the TP-Link at 192.168.250.1, but the source IP still remains 10.0.80.50.

If the TP-Link doesn't have a proper gateway or route to 10.0.80.0/24, it won't know where to send the reply back to the laptop (10.0.80.50) so the TP-Link just drops the packet.

That’s where src-nat (or masquerade) on ether1 comes in. It rewrites the source address so the TP-Link thinks the packet came from Mikrotik itself (e.g. 192.168.250.51) and sends the reply there.

McGremlin · Wed Apr 16, 2025 4:53 pm

...
TP-LINK can be special - you can try to reach it by port 80 (HTTP), it automaticly transfers it to port 443 (HTTPS) because of it's configuration and you cannot reach it. DST-NAT rule like yours works only when ports are the same on both sides (80 -> 80, 443 -> 443, etc.). If you connect "real" clients it should work.
Ahhh ok that might explain many things. I lack an extra PLC to play with or a raspi or another laptop with full control over it at this moment, so I used that as a cheap client, and obviously failed miserably, nice.

Why only partially? What do you mean?
Partially, because this scope does not have a webserver, it just has some sort of listener on port 3000 and then you can connect management app and check current status of screen. It seems to work and it stop working when i pull ethernet from scope, so there is that. Likely works ok, but with this limited way of testing I can't say for sure.

And why are you using DST-NAT and not "normal" communication with static route on main router?
Mainly, because when this is fully up and running, i will have likely 10-20 Mikrotiks, each with 3 WAN IPs (router, PLC, HMI), all in 10.0.80.0/24 network. And on each LAN of those Mikrotiks will be the actual PLC and HMI devices, which on half of them are sitting at 192.168.250.1 and 192.168.250.100, other half is semi-randomly placed in 192.168.xxx.xxx land.

I ultimately want to achieve two things (and very likely the same things that other automation people visiting this forum are trying to achieve).

1 - translate the 2nd and 3rd WAN IP to PLC and HMI, respectively, so I can access them directly from a server sitting at 10.0.80.100, which will use NodeRED to read out running data. Mainly to prevent IP conflicts.
2 - use this directly assigned WAN addresses to be able to program all machines from my workstation, without using VPN to the router

1 - seems possible without many issues
2 - I shot myself into foot, because very often the less developed devices do not allow to set a PLC/HMI address for the device, but contact it via different IP address. Meaning, that if I am in Mikrotik LAN with laptop at 192.168.250.50 and trying to program PLC at 192.168.250.1, all is well. However, if I move the laptop to 10.0.80.101 and access via mikrotik WAN 10.0.80.201, I can't connect to it without setting the target PLC address in programming software to 10.0.80.201, which will then set the ETH port on PLC to this IP on first transfer to PLC, and machine will promptly cease function. So here the proper solution would be to have Mikrotik act as OpenVPN server and each time I want to change code, VPN into local subnet of specific machine.

Understood now. So the next question is - will the islands communicate with each other (HMI1 -> Mikrotik -> main router -> Mikrotik -> HMI2) or you will only read out data/signals from them via NodeRED?

1 - doable.
2 - cannot say, in my network and OT environment programmers are doing it while being inside supervisor/supervision subnet (maybe for a reason).

Larsa is making a good point too.

chaosinc · Wed Apr 16, 2025 8:25 pm

Thank you both. I have applied the src-nat after explanation, it definitely makes sense.

The machine islands of PLC+HMI sets will not and should not talk to each other at all, I just need them accessible from one server which will be sitting in 10.0.80.0/24, same as MIkrotik WANs.

I will sort my point 2 with OpenVPN. Some PLC manufacturers have this sorted (such as B&R, I can contact PLC at 10.0.0.2, which is going through a VPN server, router, all kinds of magic to end up at 192.168.9.100 on the other side of the world and it works perfectly), some simply consider PLC-IP = contact-me-at-this-IP and there is no way around that (hello older Omron).

The moment I have this up and running correctly, I shall post my config so it can be of use to someone else later.

//EDIT and about the OT network devices programming, I have seen multiple approaches. One is VPN per machine, one is VLAN per machine and then in the office there is one switch port where engineer will change VLAN to his target network and then commences whatever he needs to do in machine subnet.

jaclaz · Thu Apr 17, 2025 11:04 am

My difference from the existing threads (and yes, I am also in industrial automation world) is, that I am not trying to achieve same LAN device IPs to separate WAN IPs (as in "you have 4 PLCs with same IP, give them 4 different WAN addresses, so the other servers can address them as such"), but I am trying to make two specific IPs from LAN visible on two WAN IPs.

I am struggling to understand the actual difference.
Some people have two (or more) machines with the same IP that need to be reached remapping them to other different IP's (usually based on which port they are connected to).
You have two (or more) machines with different IP's that need to be reached remapping them to other diffeerent IP's.
Isn't your case a subset of the former?

If this is the case, maybe you might find of interest this thread:
viewtopic.php?t=213056

McGremlin · Thu Apr 17, 2025 11:42 am

My difference from the existing threads (and yes, I am also in industrial automation world) is, that I am not trying to achieve same LAN device IPs to separate WAN IPs (as in "you have 4 PLCs with same IP, give them 4 different WAN addresses, so the other servers can address them as such"), but I am trying to make two specific IPs from LAN visible on two WAN IPs.
I am struggling to understand the actual difference.
Some people have two (or more) machines with the same IP that need to be reached remapping them to other different IP's (usually based on which port they are connected to).
You have two (or more) machines with different IP's that need to be reached remapping them to other diffeerent IP's.
Isn't your case a subset of the former?

If this is the case, maybe you might find of interest this thread:
viewtopic.php?t=213056

Here is why:

Mainly, because when this is fully up and running, i will have likely 10-20 Mikrotiks, each with 3 WAN IPs (router, PLC, HMI), all in 10.0.80.0/24 network. And on each LAN of those Mikrotiks will be the actual PLC and HMI devices, which on half of them are sitting at 192.168.250.1 and 192.168.250.100, other half is semi-randomly placed in 192.168.xxx.xxx land.

There are the same IP's on different machine network islands and he wants to check signals from all of them.

And to the author:

The machine islands of PLC+HMI sets will not and should not talk to each other at all, I just need them accessible from one server which will be sitting in 10.0.80.0/24, same as MIkrotik WANs.

It's quite good for you because in different scenario you would struggle with it especially if they would be treated as a part of bigger machine/process where signal and data time synchronization is crucial. But it's not your case, we don't need to look at it

//EDIT and about the OT network devices programming, I have seen multiple approaches. One is VPN per machine, one is VLAN per machine and then in the office there is one switch port where engineer will change VLAN to his target network and then commences whatever he needs to do in machine subnet.

VLAN's are the thing in my environment but won't help you without changing IP addressess on PLC's and HMI's to unique ones so openVPN sounds great.

Larsa · Thu Apr 17, 2025 12:52 pm

Thanks, but is there anything new here for @chaosinc to consider, or did I miss something? Anyway, we had a thread about a similar setup for a production plant last year. I’ll see if I can dig it up.

chaosinc · Thu Apr 17, 2025 1:51 pm

I have updated RouterOS to 7.18.2, OpenVPN works perfectly for the programming use, but that is off topic now.

I got a second laptop, did not bother to use xampp or anything, just went for the integrated remote desktop.

Laptop is static 192.168.250.99 and when I openvpn into router LAN, I can access remote desktop fine.
Added an address to mikrotik WAN at 10.0.80.203
Added DST-NAT and SRC-NAT rules as follows:

chain=dstnat action=dst-nat to-addresses=192.168.250.99 dst-address=10.0.80.203 log=yes log-prefix=""
chain=srcnat action=src-nat to-addresses=10.0.80.203 src-address=192.168.250.99 out-interface=ether1 log=yes log-prefix=""

RDP fails to connect. I can see in log that this connection comes through firewall. I have opened firewall fully just in case, it accepts all input and forward chains.

dstnat: in:ether1 out:(unknown 0), connection-state:new src-mac 94:ff:3c:92:38:b7, proto TCP (SYN), 10.0.10.206:57523->10.0.80.203:3389, len 52

I see this in packet sniffer (looks like port changed, this was 2nd try):

15 1.110 ether1 rx 10.0.10.206 58013 10.0.80.203 3389 ip tcp 66
16 1.110 bridge tx 10.0.10.206 58013 192.168.250.99 3389 ip tcp 66
17 1.110 ether2 tx 10.0.10.206 58013 192.168.250.99 3389 ip tcp 66

Before I install Wireshark on the mikrotik LAN laptop, how does this feel to you? Where can I deeper logs, such as DST-NAT translation from 10.0.80.203 to 192.168.250.99? This seems that the translation worked, maybe it even got to laptop, but it did not respond correctly. I have on purpose NOT filled gateway in laptop LAN settings, so I presumed the src-nat would capture everything coming from 192.168.250.99 IP, translate it to 10.0.80.203 and send it back out.

EDIT - Right, so after changing laptop LAN to gateway 192.168.250.51 (which is mikrotik LAN IP), RDP works

So, now the question remains - how can I make this work without gateway settings, since some PLC devices are not really built for that?

Thank you for your efforts!

Larsa · Thu Apr 17, 2025 2:15 pm

All PLCs with TCP support that I’ve worked with allow basic network settings like dynamic or static IP address, subnet mask, DNS, and default gateway. What brand are you using in this case?

lurker888 · Thu Apr 17, 2025 2:48 pm

What the OP is about is a fairly standard ask in the automation field. Just some points:
* Yes, most PLCs, sensors, relays etc. allow you to set an address, netmask, gateway and usually offer DHCP support. Somehow the guys doing these sorts of things don't want to set this up correctly. I don't know why, because most of the people working on these things are quite bright, so it's certainly not a matter of cognitive ability, more of a "culture thing".
* Some basic routers that I have seen - are are quite commonly encountered in these places - actually do masquerade an internal address when "port forwarding" is setup. Maybe they just have a masquerade rule on them without any match criteria? Dunno. But I certainly had to fix the problem of there not being a default gateway assigned numerous times, so I just include the rule to masquerade traffic.
* Actually separating the different PLC/sensor etc. groups into subnets/VLANs etc. makes quite a bit of sense if they control mainly independent things.

I'm sorry to say that OP's exposition of the problem has all the hallmarks of how *not* to ask a question:
* drip-feeding information
* starting off from some corner of the problem space and then expanding it into the complete solution - this doesn't really work
* not providing a complete diagram of the setup or description of what they want
* not knowing what they want

In general, there are two solutions to remotely and securely access these setups :
* leave the addressing alone, put the given interfaces into VRFs and then initiate VPN connections into these VRFs. Both openvpn (via profiles/interface lists or static interfaces) and wireguard (multiple servers on different ports) can be used for this sort of setup. Here nat and other trickery are optional.
* map the different sets of devices onto different interfaces and use nat and routing/mangle to assign e.g. 172.16.10.x to the first set of devices mapped to 168.192.2.x, 172.168.11.x to 168.192.2.x for the second set of devices, etc. and then create a VPN that has visibility into all of them at once

Which of these is the more appropriate in the given scenario is a judgement to make. I would vote for the second one, noting that even though here all users have access to all devices by default, this can be restricted at will, and in this sense this is a more general solution.

chaosinc · Thu Apr 17, 2025 2:58 pm

PLCs are generally OK and if I have full access to them, I can set network details and all is well.

My issue is with machines where I have no OEM support. I can either guess the gateway (If PLC is .10 and HMI .20, it is likely gateway is .1), or if it was never set up, I am shit out of luck. Plus there are some Chinesium devices where IP and subnet are literally the only two things I saw in the setup interface.

Is there any way to capture stuff if gateway was not set up, or is the only way to setup a dual NIC Raspi at problematic machines and push to NodeRED from there?

---
I read lurker888's response, and I do agree, this seems I started with an XY problem. I simply wanted a "please exchange this IP for this IP and just leave me be" and turns out that most issues that I am having are due to incorrect configuration on PLC side.

Since obviously after gateway was set up correctly the DST-NAT works well, this no longer seems to be a Mikrotik related issue.

McGremlin · Thu Apr 17, 2025 3:32 pm

Maybe this would help with lack of gateways on PLC's and HMI's:

chain=srcnat action=src-nat to-addresses=192.168.250.51 src-address=10.0.80.0/24 out-interface=etherX log=yes log-prefix=""

where "etherX" is the interface where island is plugged, if HMI and PLC are connected without a switch directly to Mikrotik add a interface list of those and use out-interface-list=ThatList.

lurker888 · Thu Apr 17, 2025 3:41 pm

[...] and turns out that most issues that I am having are due to incorrect configuration on PLC side.

Src-nat takes care of that, because the devices see all connections coming from their own subnet and send answers there. So the default gateway config doesn't come up at all.

I was not just trying to poo-poo the thread. I actually gave you the two solutions (with one tunnel or with a tunnel per device group) that are entirely useful for extracting info via NodeRed, etc. So the raspy per device group is not needed. (Just as a warning: I've been around this block a few times, and as it turns out, MikroTik devices are *way* more reliable than raspberry pis, so it's best to centralize your data collection and distribute your networking/vpn setup.)

EDIT: If you are still thinking about the raspberry pis, it's fully supported to simply "ship" your ethernet segments to a central location via all sorts of ways, including VLANS, L2TP, VXLAN, openvpn TAP mode, EoIP, etc. These can of course go through encrypted tunnels. And then on the central location you have one (virtual) interface per network. (And basically you have to configure everything there, which I think would be easier on a central Mikrotik, but whatever you're more familiar with.)

chaosinc · Thu Apr 17, 2025 3:50 pm

But I shall use both DST-NAT and SRC-NAT, correct? They do not build reverse path automatically I presume.

I need to read more on src-nat then. My understanding was that this code is correct for my use case:

chain=srcnat action=src-nat to-addresses=10.0.80.203 src-address=192.168.250.99 out-interface=ether1 log=yes log-prefix=""

In here topology is as follows:
Mikrotik WAN 10.0.80.200-10.0.80.203/24 on ether1
Mikrotik LAN 192.168.250.51/24
Laptop in LAN 192.168.250.99/24 (no gateway set up on purpose), connected to ether2 via another dumb switch

I understood the srcnat command as "if 192.168.250.99 sends something, grab it and rewrite to 10.0.80.203, and send it out on ether1 interface". Am I wrong here?

McGremlin · Thu Apr 17, 2025 4:03 pm

This one

chain=srcnat action=src-nat to-addresses=10.0.80.203 src-address=192.168.250.99 out-interface=ether1 log=yes log-prefix=""

is translating to 10.0.80.203 traffic going outside only from the 192.168.250.99 addres.
This one

chain=srcnat action=src-nat to-addresses=192.168.250.51 src-address=10.0.80.0/24 out-interface=etherX log=yes log-prefix=""

should translate all traffic from 10.0.80.0/24 subnet going inside the island to Mikrotik IP 192.168.250.51 so the devices should see it as originating from their subnet without needing to use the default gateway "parameter".
Use both of them + DST-NAT rule.

lurker888 · Thu Apr 17, 2025 4:07 pm

You really should draw a proper network diagram and then we can talk about the individual rules. Also note that it's not a single rule that in itself does all the things you want, but a set of them that work together.

The whole scenario is discussed btw in quite some detail in the thread that lead to your second reference in your first post here:
viewtopic.php?t=215744

Where is the laptop in the network? I assume that because it has no gateway set on purpose, it's in the place of the plc/hmi/whatever device. You are testing a connection initiated from this device. Is this the actual use case?

And yes, proper src/dst-nat rules do solve exactly the issues with the gateway, (I think in these situations you would be better off not src/dst-natting individual addresses, but mapping entire /24 subnets, as I described in the previous post. Here netmap will be the appropriate action.)

Larsa · Thu Apr 17, 2025 4:07 pm

@chaosinc; And since there is no internet connection where you would normally use the term 'WAN', I suggest using 'PLC LAN' and 'Management LAN' to describe the different subnets.

As @lurker888 pointed out, create a simple but complete network topology that includes IP addresses for all subnets and all endpoints. This should include the laptop, both interfaces on the MikroTik and TP-Link, as well as the PLC.

chaosinc · Thu Apr 17, 2025 4:11 pm

Thank you all, I will prepare a complete topology. The laptop at the moment is just a "replacement PLC" because I know it is a device that accepts RDP connections and i have 100% control over it. But this likely introduced more confusion, so the complete topology is definitely the way to go.

chaosinc · Thu Apr 17, 2025 5:44 pm

I apologize if text-based topology is common on this forum, I can edit the post if so.
We can ignore the openvpn stuff for programming use, because that simply works perfectly. If I want to program a PLC/HMI, I openvpn to Mikrotik, then I am in machine subnet and everything works great.
We can ignore any TPlinks I mentioned previously, those were just "instead-of-PLC" placeholders, so I can test this on bench before going to production.

What I ultimately want to achieve is to have NodeRED running on the Desktop in MGMT LAN. This will contact 10.0.80.201 which is at Mikrotik hex, which should translate it to 192.168.250.1 in PLC LAN, so NodeRED talks to the PLC.

Since I wanted to be absolutely sure I am not having PLC/HMI issues, I have used another laptop, called RDP test laptop on topology. Gave it static 192.168.250.99/24.
If RDP test laptop has gateway set to Mikrotik at 192.168.250.51, RDP from Desktop to 10.0.80.203 does work.
If RDP test laptop has no gateway set up, RDP from Desktop to 10.0.80.203 does not work.

This is my current configuration. 1 DSTNAT and 2 SRCNAT, just to try to make the RDP test laptop connection work. I have fully opened firewall until I am sure things work as I want.

/interface bridge
add admin-mac=____________ arp=proxy-arp auto-mac=no comment=defconf name=bridge port-cost-mode=short
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/ip pool
add name=ovpn-pool ranges=192.168.250.200-192.168.250.220
/ip smb users
set [ find default=yes ] disabled=yes
/ppp profile
add local-address=192.168.250.199 name=ovpn remote-address=ovpn-pool
add bridge=bridge dns-server=192.168.250.51 local-address=192.168.250.51 name=VPN-Profile remote-address=ovpn-pool use-encryption=yes
/routing bgp template
set default disabled=no output.network=bgp-networks
/routing ospf instance
add disabled=no name=default-v2
/routing ospf area
add disabled=yes instance=default-v2 name=backbone-v2
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5 internal-path-cost=10 path-cost=10
/ip firewall connection tracking
set enabled=yes udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server server
add auth=sha1 certificate=server-cert cipher=aes256-cbc default-profile=VPN-Profile disabled=no mac-address=_______________ name=ovpn-server1 require-client-certificate=yes
/ip address
add address=192.168.250.51/24 comment=defconf interface=bridge network=192.168.250.0
add address=10.0.80.200/24 comment="wan primary ip" interface=ether1 network=10.0.80.0
add address=10.0.80.201/24 interface=ether1 network=10.0.80.0
add address=10.0.80.202/24 interface=ether1 network=10.0.80.0
add address=10.0.80.203/24 interface=ether1 network=10.0.80.0
/ip dhcp-server
add address-pool=ovpn-pool interface=bridge lease-time=10m name=defconf
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.250.51 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input
add action=accept chain=forward
add action=accept chain=input dst-port=1194 protocol=udp
add action=accept chain=input dst-port=1194 log=yes protocol=tcp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" log-prefix=icmp protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.0.80.203 log=yes to-addresses=192.168.250.99
add action=src-nat chain=srcnat log=yes out-interface=ether1 src-address=192.168.250.99 to-addresses=10.0.80.203
add action=src-nat chain=srcnat out-interface=bridge src-address=10.0.80.0/24 to-addresses=192.168.250.51
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=10.0.80.1
/ip smb shares
set [ find default=yes ] directory=/flash/pub
/ppp secret
add name=client1 profile=ovpn
add name=maintenance profile=VPN-Profile service=ovpn
/routing bfd configuration
add disabled=no interfaces=all min-rx=200ms min-tx=200ms multiplier=5
/system clock
set time-zone-name=Europe/Belgrade
/system identity
set name=RouterOS
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

Larsa · Thu Apr 17, 2025 6:03 pm

@chaosinc; Much better! Just a few quick follow-up questions and suggestions to make the diagram easier to follow:

Which VLANs are the different subnets actually connected to?

To make the diagram clearer, I’d suggest labeling each subnet with its corresponding VLAN ID right where it applies. For example, put “VLAN10 – 10.0.10.0/24” near the MGMT LAN and “VLAN80 – 10.0.80.0/24” near the PLC LAN or the MikroTik interfaces, depending on where they belong. (and so on)

A few other small things that could make the diagram even easier to follow:
- Show which VLANs are trunked through the Cisco switch, and which ports are access or trunk.
- Add labels like “VPN Server” and “VPN Client” next to the devices playing those roles.
- Keep the IP formatting consistent (try not to mix notations like slashes and full address ranges unless it adds clarity).
- You could also add arrows or simple notes showing NAT translations, for example between 10.0.80.203 and 192.168.250.99, to help visualize the flow.

jaclaz · Thu Apr 17, 2025 6:44 pm

There are the same IP's on different machine network islands and he wants to check signals from all of them.

Which still seems to me like another subset of the same, in any case the solution there was the same dst-nat (or netmap) + mangle rules to mark packets depending on ports connected, in the case of one "island" with different IP's there is no need of the mangle.
Multiple islands, each with different IP connected machines won't need 'em either, since once the LAN is translated to WAN (hopefully not to a conflicting address) there won't be any duplication.

In that thread masquerade is used instead of src-nat, but that should be irrelevant.

chaosinc · Thu Apr 17, 2025 9:53 pm

I believe this might illustrate situation better.
I dropped the VLAN indications and actually for all testing I have desktop directly in 10.0.80.X, so everything happens in 10.0.80.0/24 subnet of Main Cisco router.
Added desired NAT translations near Mikrotik.
All subnets in all devices are always 255.255.255.0, so I have also dropped the inconsistent /24

lurker888 · Fri Apr 18, 2025 12:57 am

Your diagram is still incomplete/incorrect.

My notes:
* You say that you want addresses 10.0.80.200-203 (4 addresses) on the ether1 side. I will assume:
* You want to use one for managing the your Mikrotik router. Let's assume that's 10.0.80.200. This we will have as a /24 address.
* You want to use 10.0.80.201-203 to access 192.168.250.1,100,99 respectively. These addresses will be /32 addresses. (It's just better this way, trust me)
* I'm a bit stumped that the PLC would have the 192.168.250.1 address by default. Usually the gateway has either the .1 or .254 address (usually English speaking countries use .1 and German speaking ones user .254, just for fun

), but no one usually assumes that the PLC will be the GW. This is of no consequence really, and .51 is as good as any other. But this makes me question whether this is really a default configuration or someone just has some idea...

There is nothing special in this and is easily accomplished with the following:

### Addresses
/ip/address
# Management address
add interface=ether1 address=10.0.80.200/24

# Addresses that we will dst-nat
add interface=ether1 address=10.0.80.201/32
add interface=ether1 address=10.0.80.202/32
add interface=ether1 address=10.0.80.203/32

# Address on the device network side
add interface=ether2 address=192.168.250.51/24

### NAT
/ip/firewall/nat
# dst-nat for forwarding
add chain=dstnat dst-address=10.0.80.201 action=dst-nat to-addresses=192.168.250.1
add chain=dstnat dst-address=10.0.80.202 action=dst-nat to-addresses=192.168.250.100
add chain=dstnat dst-address=10.0.80.203 action=dst-nat to-addresses=192.168.250.99

# src-nat for devices not being aware of the gateway
add chain=srcnat out-interface=ether2 action=src-nat to-addresses=192.168.250.51

That's all there is to it.

jaclaz · Fri Apr 18, 2025 1:45 am

Many (all?) Omron plcs actually use 192.168.250.1 as default IP, example:
https://www.myomron.com/index.php?artic ... &action=kb

Which prompts the question about which gateway Is commonly used in Japan?

Larsa · Fri Apr 18, 2025 2:35 am

No, that's just for the CS-series (EIP2 and EIP21S). Most Omron PLCs with built-in TCP/IP support use DHCP nowadays. Gateways, Modbus adapters, and Sysmac controllers require manual configuration using Sysmac Studio or CX-Programmer via USB.

lurker888 · Fri Apr 18, 2025 2:47 am

Again, the culture around PLCs, networks and their users is really messed up somehow. An especially common one is that they assume that masquerading on every interface of a router is normal, e.g. even when no nat is done but two subnets are involved and the PLC is being accessed from a different one, they refuse to set up a default gateway, because for some old tp-link router it worked, and probably the new router is faulty.

EDIT: and yep, the ones I've seen default to DHCP.

Larsa · Fri Apr 18, 2025 2:57 am

Yeah, it’s unfortunately more common than you might think, especially at small and mid-sized facilities designed by “old-school PLC guys” who lack basic networking knowledge.

lurker888 · Fri Apr 18, 2025 3:04 am

Yeah, it’s unfortunately more common than you might think, especially at small and mid-sized facilities designed by “old-school PLC guys” who lack basic networking knowledge.

Not disagreeing with you. However what *really* surprised me is that I used to work with a bunch of young and *very* talented guys, who actually did have basic networking knowledge, and I've seen them set up basic networking totally correctly. Even when they had questions, they made sense. But as soon as the PLCs came out, it was as if they had suddenly forgotten about what they were doing a mere hour ago, and set up the PLCs according to some 20 year old "set up your PLC in 12 easy steps" guide written by someone who had no networking knowledge whatsoever. That's what I couldn't understand and to this I actually don't.

chaosinc · Sat Apr 19, 2025 5:31 pm

Thank you all very much for your time, problem is solved by application of DST and SRC nat rules as suggested by lurker888's last post with modification from ether2 to bridge, plus enabling proxy-arp on bridge (ether2-5).

NodeRED running on desktop can access the PLC in Mikrotik Machine LAN, via 10.0.80.201 (NAT to 192.168.250.1).
NodeRED OMRON FINS settings need to be according to Machine LAN. Important part being DA1 = last octet of IP address of PLC (in this case .1, not .201) and SA1 = last octet of who is asking (here .51, since as far as PLC is concerned, packets come from Mikrotik directly)

{
  "host": "10.0.80.201",
  "port": 9600,
  "protocol": "udp",
  "DNA": 0,
  "DA1": 1,
  "DA2": 0,
  "SNA": 0,
  "SA1": 51,
  "SA2": 0
}

After this, Read request from A642, length 2 (= read two analogue inputs of the PLC) works perfectly, as seen in bottom right of this image.

For OMRON PLC CP1L-E it is NOT possible to set a gateway. Now I do not need it anymore, but in case someone is searching for this, the OMRON suggested workaround is to use "IP router table" in Ethernet settings and add 0.0.0.0 -> IP_OF_ROUTER/GATEWAY there.
I am happy here, since internal PLC settings stay at 192.168.250.1, but I am able to set CX-Programmer to talk to PLC at 10.0.80.201, so basic of networking are working at least. Not so lucky with some Chinese PLCs and HMIs which I sadly have in production too. But that is OK, since I can always use OVPN for programming needs.

My full router config attached:

[admin@RouterOS] > export 
# 2025-04-19 17:23:37 by RouterOS 7.18.2
# software id = 1E6V-AUYV
#
# model = RB750Gr3
# serial number = ************
/interface bridge
add arp=proxy-arp name=bridge port-cost-mode=short
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/ip pool
add name=ovpn-pool ranges=192.168.250.200-192.168.250.220
/ip smb users
set [ find default=yes ] disabled=yes
/ppp profile
add bridge=bridge dns-server=192.168.250.51 local-address=192.168.250.51 name=VPN-Profile remote-address=ovpn-pool use-encryption=yes
/routing bgp template
set default disabled=no output.network=bgp-networks
/routing ospf instance
add disabled=no name=default-v2
/routing ospf area
add disabled=yes instance=default-v2 name=backbone-v2
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5 internal-path-cost=10 path-cost=10
/ip firewall connection tracking
set enabled=yes udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server server
add auth=sha1 certificate=server-cert cipher=aes256-cbc default-profile=VPN-Profile disabled=no mac-address=************ name=ovpn-server1 require-client-certificate=yes
/ip address
add address=192.168.250.51/24 interface=ether2 network=192.168.250.0
add address=10.0.80.200/24 interface=ether1 network=10.0.80.0
add address=10.0.80.201 interface=ether1 network=10.0.80.201
add address=10.0.80.202 interface=ether1 network=10.0.80.202
add address=10.0.80.203 interface=ether1 network=10.0.80.203
/ip dhcp-server
add address-pool=ovpn-pool interface=bridge lease-time=10m name=defconf
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.250.51 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input disabled=yes
add action=accept chain=forward disabled=yes
add action=accept chain=input dst-port=1194 protocol=udp
add action=accept chain=input dst-port=1194 log=yes protocol=tcp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" log-prefix=icmp protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.0.80.201 to-addresses=192.168.250.1
add action=dst-nat chain=dstnat dst-address=10.0.80.202 to-addresses=192.168.250.100
add action=dst-nat chain=dstnat dst-address=10.0.80.203 to-addresses=192.168.250.99
add action=src-nat chain=srcnat out-interface=bridge to-addresses=192.168.250.51
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=10.0.80.1
/ip smb shares
set [ find default=yes ] directory=/flash/pub
/ppp secret
add name=maintenance profile=VPN-Profile service=ovpn
/routing bfd configuration
add disabled=no interfaces=all min-rx=200ms min-tx=200ms multiplier=5
/system clock
set time-zone-name=Europe/Belgrade
/system identity
set name=RouterOS
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

lurker888 · Sat Apr 19, 2025 6:52 pm

Glad it works.

You shouldn't use proxy-arp btw. You only need it because the address is on ether2 instead of the bridge. When an interface is part of a bridge, all IP related configuration should be done on the bridge.

McGremlin · Tue Apr 22, 2025 1:06 pm

So you could just add this rule without spending time for preparing network diagram

Maybe this would help with lack of gateways on PLC's and HMI's:
Code: Select all
chain=srcnat action=src-nat to-addresses=192.168.250.51 src-address=10.0.80.0/24 out-interface=etherX log=yes log-prefix="" 
where "etherX" is the interface where island is plugged, if HMI and PLC are connected without a switch directly to Mikrotik add a interface list of those and use out-interface-list=ThatList.

Maybe it was a bit confusing with mentioning the "etherX" and potentially interface lists

Have in back of your head that in the future use the Mikrotiks (192.168.250.51) as a NTP server for PLC's and HMI's or for sending e-mail notifications about network state of PLC's and HMI's - of course if such needs arise. And you should be good

DST-NAT for multiple wan addresses [SOLVED]

DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses [SOLVED]

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses

Re: DST-NAT for multiple wan addresses