DST-NAT for multiple wan addresses

RouterOS Beginner Basics
1

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:
http://forum.mikrotik.com/t/rs305-1g-4s-map-4-devices-with-same-ip-to-different-ips/183026/4
http://forum.mikrotik.com/t/quick-guide-bidirectional-1-1-nat-snat-dnat-setup-w-working-example/183024/1
http://forum.mikrotik.com/t/multiple-ip-addresses-on-eth1-wan-nat-routing-help/158601/1

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
2

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.

3

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).

4

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.

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.

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.

5

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.

6

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.

7

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.

8

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.

9

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:
http://forum.mikrotik.com/t/port-based-routing-to-2-identical-ip/180504/1

10

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 :slight_smile:

//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.

11

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.

12

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.

> ```text
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), **[u]RDP works[/u]**

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!
13

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?

14

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.

15

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.

16

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.

17

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.)

18

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?

19

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.

20

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:
http://forum.mikrotik.com/t/1-1-nat-dnat-configuration-help/182840/1

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.)