DST-NAT with three WAN interfaces

RouterOS General
1

I am trying to solve this issue but cannot get it right. Now I am all messed up and cannot thing of a solution.

I have one MT with three WAN interfaces and one LAN interface. I have server connected to LAN and I want to set dst-nat port TCP 9500 on all wan interfaces to local server.

What think I got is that dst-nat works, server gets incoming requests and sends responses but router does not always pass response to the same interface which request came from.

It hapens that approximately one third of connection attemts succeed, which hints me that router does some kind of round robin among three wan interfaces to balance, and as there are three interfaces every third connection is passed to the interface request came from.

How can I control this? I want router to always pass response to the same wan interface request came from?

2

What are your DST-NAT rules?

3 
add action=dst-nat chain=dstnat disabled=no 
      dst-address-list=public_ip 
      dst-port=9500 protocol=tcp 
      to-addresses=10.50.10.13

Address list public_ip contains IP addresses of WAN interfaces. I tried also with separate rules for each IP address with the same results (as expected).

4

yes, you should mark all incoming connections from different interface and then route them back via the interface they came from

5

Hmmm, after this remark of yours, i recall that today, while reading tons of stuff, I actualy read something that semeed to me as: if I mark incoming connection, mark will be valid for both request and response.

Is that you are referrring to. It that is true then I’ve been blinded for several years, as I assumed that request and response are two separate connections. I am going to try this at once.

6

Here is a working config with a T1 and a DSL modem… you must mark connection, mark packet, then mark routing. You also need to make sure you recreate the routing tables for each, even connected routes.

/ip firewall mangle 
add action=mark-connection chain=prerouting \
    comment="inbound DSL connections" disabled=no \
    in-interface=1-DSL new-connection-mark=in-dsl-conn \
    passthrough=yes 
add action=mark-packet chain=prerouting comment="" \
    connection-mark=in-dsl-conn disabled=no \
    new-packet-mark=in-dsl-packet passthrough=yes 
add action=mark-connection chain=prerouting \
    comment="inbound T1 connections" disabled=no \
    in-interface=2-T1 new-connection-mark=in-t1-conn \
    passthrough=yes 
add action=mark-packet chain=prerouting comment="" \
    connection-mark=in-t1-conn disabled=no \
    new-packet-mark=in-t1-packet passthrough=yes 
add action=mark-packet chain=input comment="" \
    connection-mark=in-t1-conn disabled=no \
    new-packet-mark=in-t1-packet passthrough=yes 
add action=mark-packet chain=output comment="" \
    connection-mark=in-t1-conn disabled=no \
    new-packet-mark=in-t1-packet passthrough=yes 
add action=mark-routing chain=prerouting comment="" \
    disabled=no new-routing-mark=t1 \
    packet-mark=in-t1-packet passthrough=yes 
add action=mark-routing chain=input comment="" disabled=no \
    new-routing-mark=t1 packet-mark=in-t1-packet \
    passthrough=yes 
add action=mark-routing chain=output comment="" disabled=no \
    new-routing-mark=t1 packet-mark=in-t1-packet \
    passthrough=yes

The above rules will also fix pings coming into the router itself and make sure they go back out the same way. Don’t forget to recreate the alternate routing table with your connected routes as they won’t be placed there automatically.

Sam

Need some help with dst-nat issue.
7

nope, ‘connection’ is two-side communication, not a ‘flow’ from one point to another =)

p.s. don’t know, how it’s applied to multicast traffic

8

Thanks guys for all this info. I cannot try now as I am inlocalnetwork. I have to go to other place to be able to acces from Internet to test. I will let you know about results.

Now I am bit confused. If MT recognizes connection as two way flow, why then is necessary to do all this mangling? Why it simply does not pass response within connection to the same interface connection originated by itself? That is the most probably what has to happen anyways?

9

at first - because ROS don’t know, from which interface connection is originated. and second - in routing ROS follows routing rules: routing tables, etc. you may want one behaviour, someone wants different download and upload interfaces… so ‘the most probably’ is open question

10

Well, I had no success.

First, action=mark-routing in chain=input as suggested is not possible. Then action=mark-routing in chain=prerouting block any kind od connection through that interface.

I tried this:

/ip firewall mangle

add action=mark-connection chain=prerouting in-interface=ptt new-connection-mark=in-ptt-con passthrough=yes

add action=mark-packet chain=prerouting connection-mark=in-ptt-con new-packet-mark=in-ptt-packet passthrough=yes

add action=mark-packet chain=input connection-mark=in-ptt-con new-packet-mark=in-ptt-packet passthrough=yes

add action=mark-packet chain=output connection-mark=in-ptt-con new-packet-mark=in-ptt-packet passthrough=yes

add action=mark-routing chain=prerouting new-routing-mark=ptt-route packet-mark=in-ptt-packet passthrough=yes

add action=mark-routing chain=output new-routing-mark=ptt-route packet-mark=in-ptt-packet passthrough=yes

and routing table looks like this:

0 A S  dst-address=0.0.0.0/0 gateway=214.201.191.127 interface=pppoe-adsl gateway-state=reachable distance=10 scope=255 target-scope=10 routing-mark=adsl-route 

 1 A S  dst-address=0.0.0.0/0 gateway=81.118.219.17 interface=sbb gateway-state=reachable distance=10 scope=255 target-scope=10 routing-mark=sbb-route 

 3 A S  dst-address=0.0.0.0/0 gateway=88.120.227.241 interface=ptt gateway-state=reachable distance=10 scope=30 target-scope=10 routing-mark=ptt-route 

 4 ADS  dst-address=0.0.0.0/0 gateway=214.201.191.127 interface=pppoe-adsl gateway-state=reachable distance=1 scope=30 target-scope=10
11

also recreate your ‘connected’ routes from main table in your alternate routing tables. Use the router IP on that subnet as the gateway for those alternate entries.

12

Interesting, I removed all mangling from router, and set just one default gateway. It stays that way for two days and I see no problems, incoming connections look like routed back to originating interfaces as I need them.

Default gateway seems as not having influence on that connections and there is no need to mangle.

Is there any tool with which I can track down what actually happens with request and response packets within router?

recreate your ‘connected’ routes from main table in your alternate routing tables

I must admit I am not sure what this actually means. In main table I have only default gateway rule, and for each connection-mark I have specific gateway rule, and that is all.

I have other rules in main routing table but they are for local network and they are insignificant for what I am trying to do.

13

Good Day.

I am experiencing exactly same issue and have yet too resolve, looking into a non ROS solution as we currently have a few lines lying around unused because of this issue.

I also could not come rite with info here and it seems also that the rules suggested as a working example are not consistent as i do not see anywhere near the amount of mangles on the dsl side.


and i too not sure of what’s meant by

recreate your ‘connected’ routes from main table in your alternate routing tables

14

Also for those interested i have another topic open here http://forum.mikrotik.com/t/need-some-help-with-dst-nat-issue/31205/19 that has some screen shots of my traffic and the results.