I've got it!!!!!!!
Had some time over so I decided to set up a test environment and try to figure this out..... I can say that it wasn't completely clear and I had quite a few thoughts about just giving up on the whole thing
Anyway, here's the setup.
6 MT routers
User1, ether1 192.168.101.50/24
- gateway 192.168.101.1
- connected ether1 to MT ISP1 / ether1
ISP1, ether1 192.168.101.1/24 / ether2 192.168.102.1
- connected ether2 to MT Central / ether2
- static route 192.168.2.0/24 to 192.168.102.2 (central -> my network)
User2, ether1 192.168.111.50/24
- gateway 192.168.111.1
- connected ether1 to MT ISP2 / ether1
ISP2, ether1 192.168.111.1/24 / ether2 192.168.112.1
- connected ether2 to MT Central / ether3
- static route 192.168.2.0/24 to 192.168.112.3 (central -> my network)
Central
- ether1 192.168.120.1/24
- ether2 192.168.102.2/24
- ether3 192.168.112.3/24
- ether4 192.168.2.221/24 (my network)
Firewall
- ether1 192.168.2.1
- ether2 DHCP from my ISP
- static routes for the networks added to 192.168.2.221
Setup on Central is as follows
/ ip route
add dst-address=0.0.0.0/0 gateway=192.168.112.1 disabled=no
add dst-address=0.0.0.0/0 gateway=192.168.102.1 routing-mark=route-eth2 disabled=no
I
am using the path to User2 as default, anything marked with route-eth2 should be sent over the path to User1
/ ip firewall connection tracking
set enabled=yes tcp-syn-sent-timeout=1m tcp-syn-received-timeout=1m \
tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-close-wait-timeout=10s \
tcp-last-ack-timeout=10s tcp-time-wait-timeout=10s tcp-close-timeout=10s \
udp-timeout=10s udp-stream-timeout=3m icmp-timeout=10s generic-timeout=10m
Make sure you have decent values here, EVERYTHING depends on the connection tracker! I used default for this test
/ ip firewall mangle
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=con-eth2 passthrough=yes disabled=no
add chain=prerouting in-interface=ether4 connection-mark=con-eth2 action=mark-routing new-routing-mark=route-eth2 passthrough=no disabled=no
This pulls it together;
- the first rules marks everything that comes in (that can be tracked by the connection tracker!) on ether2 with a connection mark con-eth2
- the second rule takes everything with connection mark con-eth2 and marks it for routing with routing mark route-eth2
NOTE that the second rule ALSO checks where the packets come from, ONLY packets with connection mark con-eth2 coming in on ether4 get the routing mark! Without that in-interface check nothing works at all since the traffic coming in on ether2 will also be marked for routing with route-eth2!
With this configuration in place I was able to run "/system telnet 192.168.2.1" from both the User1 and the User2 endpoint MT against the firewall MT that is behind Central MT
I hope this is clear enough for you all, I will try to make up a drawing later on
/Jörgen