LAN to LAN forwarding

RouterOS General
1

I am trying to set up forwarding rules to redirect traffic from one to another device within the same LAN so I can silently migrate services from one server to another without having to change IP adresses for everyone that’s on the LAN network. Once all services are migrated the new server will be assigned the IP of the old one and the redirect rules will be disabled.

In a bit more detail. What I’m trying to achieve is forwarding data going to old server (192.168.10.125 port 150) to new server (192.168.10.126 port 10000).

So far I managed to set up the following rules:

add action=masquerade chain=srcnat comment="Allow internet access through WAN port" ipsec-policy=out,none out-interface-list=WAN

add action=dst-nat chain=dstnat comment="External forward does work" dst-address-list=Home dst-port=150 protocol=tcp to-addresses=192.168.10.126 to-ports=10000

add action=dst-nat chain=dstnat comment="Internal forward does not work" dst-address=192.168.10.125 dst-port=150 protocol=tcp to-addresses=192.168.10.126 to-ports=10000

add action=masquerade chain=srcnat comment="Give Lan access to local devices via WAN IP" dst-address-list=LAN out-interface=bridge src-address-list=LAN

The port forward using the WAN ip works but through the LAN forward it just times out. I’ve spent nearly the entire day trying different setups and reading up on Hairpin NAT but I’m at a total loss on this one. I hope someone can help me solve this problem.

2

You need to use bridge filter and bridge nat for the traffic inside your LAN.
And even then it will work only if the path from client to server physically lies via you router.
If, for example the client and server are connected to the switch, and not to the router directly, that won’t work at all.

3

It may be simpler to temporarily dedicate a subnet different from 192.168.10.0/24 for the server, so that the clients would have to use the router as a gateway. Bridge NAT rules are a nightmare (ARP handling is necessary, NAT is not stateful…)

4

Thanks to the both of you for the reply. It seems this answer from sindy is the easiest to setup:


I have created a new subnet and assigned the new server and ip on it (192.168.12.25) but I still have the same forwarding problem. Would it be possible to provide me with an example of how I should redirect my traffic from 192.168.10.125:150 to 192.168.12.10000?

5

Traffic inside your LAN is a Layer 2 traffic that will not go through The Firewall !!! Firewall filters Layer 3 Traffic…
So either you enable the bridge filter so that the traffic is forced to pass through the prerouting, forward and postrouting chains, as @xvo suggested or you use a whole different subnet for your server as @sindy suggested…

Personally i would go with @sindy’s suggestion…

6

The “internal dst-nat” rule you’ve posted in one of the previous posts was OK for this purpose, so it’s most likely just a typo in it, or you have done something wrong when adding the dedicated subnet for the new server. So if you don’t find the typo, follow the suggestion in my automatic signature below.

7

Port forwarding from wanIP:port to lanIP:port works.
What the OP wants to know is how to port forward from internal lanIP1:port to internal lanIP2:port .
Me too interested in the solution. :slight_smile:

8

It’s not exactly like this - what the OP really wants is to migrate services from old server to new server one by one without touching the clients’ configuration, and whilst it should be possible to port forward even L2 traffic, the amount of hair lost while debugging it would not be proportional to the outcome. And as the real goal can be achieved using simpler means, it is unlikely that the question above will be answered here :slight_smile:

9

Okay I will bite as its not clear to me.

By the way first of, I would introduce the server at a quiet time and do the switch period.
I dont see why one needs to do it slowly like over a few days. Set it up in the LAB and then simply deploy it, you know, plug in for power, take out ethernet cable from old server and plug cable into new server, unplug power to old server, remove old server. :slight_smile:

The way I read it is that the OP has the following scenario.
Bunch of users on SUBNET A, and a server on SUBNET A.
THe OP wants to move everyone over to a NEW SERVER ON SUBNET A over time so its transparent to users.

I do not understand your solution as it makes too many assumptions.
What if lan users use the LANIP and port number of the server…

Are you suggesting that users be instructed to use a DYNDNS name (IE GO through the WANIP for server access). Invoking Hairpin NAT or loopback LOL.

CHANGE METHOD OF ACCESSING SERVER (using hairpin)
If So, the dst nat rules would be on day one Prior to Server Changes
dstport=XXX (current) to IP-- currentserverip to port= XXXX original

CHANGE DESTINATION NAT RULE
Day Two Admin puts the new server in place and changes the rule.
dstport=XXX (current) to-ip --newserver to port=YYYY new IP/new port

RETURN DST NAT RULE
Once the migration is satisfactorily completed and op changes new server IP and port back to original numbers.
dstport=xxxx current to ip-currentnew to port=xxxx original

10

@sindy, I’m looking for a solution for port-forwarding from lanIP1:port to lanIP2:port within the same LAN. Is there a solution available for this (simpler) problem?
Ie. connections to 192.168.88.12:8512/tcp shall be (on the router) redirected to 192.168.88.11:8511

11

It’s not a simpler problem.
And there is no good solution for this.
Mostly because the concept itself is bad: while the idea of putting devices on the same L2 network pursues the goal to offload handling of traffic between hosts on this network to cheaper (and faster) devices - switches, what you are trying to achieve needs quite the opposite - that all the traffic in your LAN passes through your router (an not even it’s internal switch, but its CPU).
So not only will you need to build your whole network with that in mind, but you are at the same time making router’s CPU the whole network’s bottleneck.

12

Hi XVO you nailed the issue on the head… the concept is bad. This points out that OP is concerned with fulfilling a config solution without revealing the true requirement. Cart before the horse and the most expensive way to implement anything.
Suggest mutluit that you describe the user case(s), in terms of what users require to do their jobs etc, without any discussion of configuration or hardware involved.
What is unique, different from other requirements.
What are the limitations? (here you may state what equipment is involved, what is available to work with on the canvass so to speak).

13

ATTN everybody!
I now have found a solution. Will post it shortly. But it works only if no bridge is configured in RouterOS :frowning: Could be a ROS bug…

14

Then how exactly did you create a Layer 2 Broadcast Domain if you configured no Bridge ?

15

Ok, here’s the said solution:

Solution for port forwarding for both WAN-to-LAN as well LAN-to-LAN (incl. inside same LAN):

On my router (hAP ac^2 with RouterOS 7.0beta8) with no NAT (ie. as 2nd router) now the following solution works:

IP of WAN interface (ether1): 192.168.254.253/24
IP of ether2 (ie. the gateway IP for LAN): 192.168.127.254/17
IP of host attached to router ether2: 192.168.20.1/17 (can add more hosts into that LAN by attaching a dumb switch to ether2).

WAN port 8458 is forwarded to LAN IP 192.168.20.1:8459. There an iperf server is running for testing.

All connections to 192.168.254.253:8458 (ie. the WAN interface) are correctly redirected, even connections from inside the LAN !

So, the culprit is the bridge as with bridge this solution doesn’t function.

I first tried the following step-by-step guide (with some good explanations) that says it works,
but I couldn’t get it working here (as said WAN-to-LAN works, but not from inside the LAN):
https://serverfault.com/questions/970346/port-forwarding-test-possible-within-lan-mikrotik-router
Then I removed the bridge, and voila it works! And performance is ok (Gigabit speed, s.b.).


[admin@AP1] /ip/firewall/nat> export
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.254.253 dst-port=8458 in-interface=all-ethernet log=yes protocol=tcp to-addresses=192.168.20.1 to-ports=8459
add action=src-nat chain=srcnat dst-address=192.168.20.1 dst-port=8459 log=yes protocol=tcp src-address=192.168.0.0/17 to-addresses=192.168.127.254


[admin@AP1] /ip/firewall/filter> export
/ip firewall filter
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
…


host:

ifconfig

eth0 Link encap:Ethernet HWaddr XXXXXXXXX
inet addr:192.168.20.1 Bcast:192.168.127.255 Mask:255.255.128.0

\

iperf server running on host:

$ iperf -e -s -p 8459

\

iperf client from anywhere:

$ iperf -e -c 192.168.254.253 -p 8458 -t 5

Client connecting to 192.168.254.253, TCP port 8458 with pid 18513
Write buffer size: 128 KByte
TCP window size: 468 KByte (default)

[ 3] local 192.168.20.1 port 12146 connected with 192.168.254.253 port 8458 (ct=0.93 ms)
[ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT NetPwr
[ 3] 0.00-5.01 sec 552 MBytes 925 Mbits/sec 4417/0 0 -1K/816 us 141735.83


Btw, without the above filter rules the performance is only about half:
[ 3] 0.00-5.02 sec 314 MBytes 525 Mbits/sec 2511/0 0 -1K/695 us 94425.95
So, the “fasttrack” and the “established,related” rules should be present in the firewall to get wire-speed performance.

P.S.: of course the log=yes in the firewall rules should be removed after testing.

16

Just assign an IP to the router port, for example ether2: 192.168.50.254/24. That’s then the gateway IP for LAN 192.168.50.0/24 at ether2.
Of course w/o a bridge one loses the switch-functionality on the router, meaning one has to attach a dumb switch to ether2 to be able to attach more than one host into that LAN. Same with the other router ports…

17

I don’t exactly understand what is that thing, that is working, for you have only one host on your LAN in your example.
And even if there is a thing, and it is actually working, how is it supposed to continue to work after you put two hosts on one dumb switch?!
These two hosts will connect to each other via the switch, not via your router, no matter the configured rules.

18

It should work b/c one uses the WANGATEWAYIP:port as the WANGATEWAYIP is on the router (in my case ether1).
As said WANGATEWAYIP in my case means the uplink-interface on this 2nd router → going to the 1st router.
I’ll now test it also with a dumb switch, and also from the other router ports (ie. from other LANs).

19

@xvo, “that thing…” gave me a good laugh.

Might be a solution, but that will mean all clients will have to be reconfigured to point to WAN address and not internal address of server

20

Hmm. yes, you are right. But I think that problem is solvable too. I’ll check.

Update:
I now tested using a dumb switch, as well using from another LAN at ether3: both works using the GATEWAYIP:port.

I’ll now see whether it as well functions if one uses the (non-existent) hostIP:port instead of the GATEWAYIP:port.