add action=dst-nat chain=dstnat disabled=no dst-address-list=public_ip dst-port=9500 protocol=tcp to-addresses=10.50.10.13
/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
nope, 'connection' is two-side communication, not a 'flow' from one point to another =)I assumed that request and response are two separate connections
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 questionNow 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?
/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
0 A S dst-address=0.0.0.0/0 gateway=184.108.40.206 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=220.127.116.11 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=18.104.22.168 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=22.214.171.124 interface=pppoe-adsl gateway-state=reachable distance=1 scope=30 target-scope=10
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.recreate your 'connected' routes from main table in your alternate routing tables
recreate your 'connected' routes from main table in your alternate routing tables