DNAT where source is also translated.

RouterOS General
1

Scratching my head over this one.

I have an external devices connection to and external IP on the TIK, this has to NAT to an internal IP of a server.

The internal server has no idea about this external subnet so can’t route back to it.

So I need the TIK to change the SRC address that the packets appear to come from to the internal IP of the TIK…

So in essence all traffic appears to only come from the TIK and nothing else.

I can’t work out how to do it in this device.

Rob

2

You need to use both a DNAT and SNAT rule for the same traffic. It is not possible to combine this into one rule.

3

I have seen mention of that and tired it.

So does the SNAT get applied before the packet is forwarded out of the router to the server?

I have tried this and It does not seem to work. Followed a lot of examples etc.

Thanks

4

If I have a static route on my server to the external subnet, things work. But not if the route is removed. So I know the source is not being translated.

5

128.x.x.[50-70] are the external clients.
128.x.x.4 is the external interface IP
172.x.x.199 is the internal server
172.x.x.123 is the internal firewall address that traffic should go back to.

172.x.x.123 has no idea of the routes to 128.x.x.x

0 chain=dstnat action=dst-nat to-addresses=172.x.x.199 protocol=tcp dst-address=128.x.x.4 dst-port=5001
1 chain=srcnat action=src-nat to-addresses=128.x.x.4 src-address=172.x.x.199

Thanks

6

Look here for the packet flow: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Warning, it is complicated!

Try the src-nat with a match on the (replaced) dst-address instead of the src-address. That should work.

7

So…
1 chain=srcnat action=src-nat to-addresses=128.x.x.4 src-address=172.x.x.123

8

The abbreviated packet flow is this:

  1. packet enters RB via WAN interface
  2. dst-nat gets executed
  3. firewall does the job
  4. src-nat gets executed
  5. packet leaves through LAN interface

So for particular IP address list, the steps would be these:

  1. packet has src-address=128.x.x.50 (example), dst-address=128.x.x.4

add action=dst-nat chain=dstnat src-address=128.x.x.50 dst-address=128.x.x.4 to-addresses=172.x.x.199


At this point packet has src-address=128.x.x.50 and dst-address=172.x.x.199
3. whatever firewall does, possibly allows this packet
4. ```text
add action=src-nat chain=srcnat src-address=128.x.x.50 dst-address=172.x.x.199 <other settings> to-addresses=172.x.x.123
  1. at this point packet has src-address=172.x.x.123 and dst-address=172.x.x.199

You have to adjust the NAT rules to cover all needed WAN addresses (eitger using address range or address subnet mask) …

9

replace your 2nd rule with,

/ip firewall nat
add chain=srcnat action=src-nat in-interface=<YourWANInterface> dst-address=172.x.x.199 to-addresses=172.x.x.123
10

“failure: incomming interface match not possible in output postrouting chains”

Cheers
…

11

How would this work if you did not know the source address?



Cheers

12

You do not need to match on src-address. It is sufficient to match on protocol, port and dst-address.
So you do the dst-nat based on the protocol and port and with dst-address equal to the local address of the router, translating the dst-addr to the address of the device you want to access.
Then, also have a src-nat that sets the source address equal to the router address for such traffic towards the dst-addr of the device (and the protocol and port).

Do not apply a too-wide match (e.g. omitting the protocol and port) because you may lock yourself out of the router!

13

The DNAT is already configured with just “DST, Port, Proto,Translated address”

14

Ok, think I have it sorted..

Post by “mkx » Tue Nov 05, 2019 6:40 pm” probably gave the hints..

I ran tcpdump on the server to see what address was being forwarded and then adjusted the paramaters in the rules until I saw the src-natted address..

Server has no routing, no concept of a subnet other than 172.x.x.x/24

source = any
wan = 128.x.x.4
ehter2 = 172.x.x.123
server = 172.x.x.199


chain=dstnat action=dst-nat to-address=172.x.x.199 protocol=tcp dst-address=128.x.x.4 dst-port=5001
chain=srcnat action=src-nat to-address=172.x.x.123 dst-address=172.x.x.199


Don’t understand the logic, but if that’s how it is then fine..

Thanks

Rob

15

Ok but note that due to the way you wrote the src-nat, ALL traffic towards that address will be src-natted not only the traffic you dst-natted to that server.
This probably does not matter when your server has no routes at all, but when it would have routes to other local subnets it would cause problems.
In that case you should put the “protocol=tcp dst-port=5001” in the src-nat rule as well.

I use this method all the time to recover devices at remote sites that have fallen back to default settings.
E.g. on a radio link between MikroTik routers made using Ubiquiti WiFi radios that sometimes revert to their factory default IP of 192.168.1.20 with no routes.
Temporarily add 192.168.1.1/24 on the port it is connected to, add those two rules for tcp/443 and I can connect the device and reconfigure it.
Very handy!

16

I took source addresses from your post #5 above … and used those as illustration how to make NAT rules as speciffic as possible not to affect the rest of traffic.

With NAT rules there are two kinds of parameters:

  1. selection criteria, which define which packets will be affected by particular rule.
    Almost all parameters fall into this category, but most used are src-address, dst-address, src-address-list, dst-address-list, protocol, src-port, dst-port, in-interface, out-interface. Not all of these parameters have to be set, but one has to be careful to set selection parameters so that the rule is not “too greedy”.
  2. action parameters, which define what needs to be changed on packets.
    These are the following two parameters: to-addresses and to-ports and define the resulting value. With src-nat the corresponding src-* values get overwritten and with dst-nat the corresponding dst-* values get overwritten. If one of the two parameters is not set (most frequently to-ports is not set), then the corresponding src-* or dst-* value is not changed.

It is perfectly fine to use e.g. src-address as selection criterion in src-nat with to-addresses set … just keep in mind that first selection rules are ran against original packet[] and action is done on matching packets.
[] I used “original” meaning the packet which is being matched … which might got changed already before this NAT rule is being evaluated.

17

Can someone add some diagrams of the connectivity of these devices for this poor fella trying to follow this thread…

18

Think of LAN (172.x.x.0/24) and WAN (the rest). And devices in LAN don’t have any route defined … hence they can only communicate with devices within same L2 domain (same subnet).

Nothing complicated to picture in one’s mind :wink:

19

Just less easy to put down in rules for a relative Tik Newbie…

I guess it’s similar to the operation of Linux IPTABLES, but I have not had to touch that in 10 years.

Cheers

Rob

20

The executive engine below is the very same netfilter module. The Mikrotik’s configuration front-end is slightly different from iptables but the structure of the rules (chains, tables) is exactly the same.
As compared to iptables:

  • you have the interface lists and address lists (which are extensions to the basic netfilter),
  • you cannot change the default handling for the chain (it is always “accept”, so if you want to change this to “drop”, you have to add a “drop” rule as the last one in the chain).
  • you cannot configure dst-nat in output chain (grrr).

The fact that srcnat chain cannot refer to in-interface (and dst-nat cannot refer to out-interface) is just a feature of netfilter so no front-end cannot do anything about it. You can work this around by assigning a connection-mark to the connection in prerouting chain of mangle table (where the in-interface can be referred to) and then refer to that connection-mark in src-nat rule in the srcnat chain of the nat table.