Good morning everyone, I have a Resort with two connections a 1 terrestrial DSL , a DSL Tooway . Connection tooway not have the public IP so I can do the management of the router remotely , but at the same time is the defaul route structure , how do I keep tooway as defaul primary route and continue to have access to the Internet Terrestrial DSL for the control of routerboard ?
La Torre.png
You could use mangle to mark routing on traffic coming to the router via terrestrial DSL, then add a route with that route mark so that traffic that enters via terrestrial DSL exits via terrestrial DSL.
Route marking is the most complete method, but it can be complicated if you’re new to ROS.
A simple solution with some limitations is to create a static route to your office’s IP address (address range) via the second DSL and accept that you can only access the Mikrotik from your office.
Another solution would be to configure the Mikrotik to use L2TP to “phone home” with a VPN connection so that you could access the Mikrotik via its VPN address.
are not new routeros I started using it since version 2.9.35 … but I have never needed to make a marker packet ,
I’d rather use this solution , and maybe because I have two gateways in case of down the satellite using the land
you can help me?
Basically, you need to follow these steps:
Do connection marking on each new connection based on which interfcace the new connection arrives from, or based on which interface you’d like to force for outbound traffic on new “output” connections. Connection marking speeds up processing - for each individual packet, you match connection marks and perform action = mark routing.
Once each packet has a routing mark, you can create routes in the routing table which have the same route mark. Packets with routing marks will only follow routes with the same route mark. It’s basically creating additional routing tables (like vlans, but for routing)
So as a quick example:
/ip firewall mangle
add chain=prerouting in-interface=wan1 connection-mark=no-mark action=mark-connection new-connection-mark=wan1
add chain=prerouting in-interface=wan2 connection-mark=no-mark action=mark-connection new-connection-mark=wan2
add chain=prerouting connection-mark=wan1 action=mark-routing new-routing-mark=wan1
add chain=prerouting connection-mark=wan2 action=mark-routing new-routing-mark=wan2
add chain=output connection-mark=wan1 action=mark-routing new-routing-mark=wan1
add chain=output connection-mark=wan2 action=mark-routing new-routing-mark=wan2
/ip route
add dst=0.0.0.0/0 gateway=1.1.1.1 routing-mark=wan1
add dst=0.0.0.0/0 gateway=2.2.2.2 routing-mark=wan2
This set of commands would make the Mikrotik answer on the same ISP connection that the new connection came in through. You can expand on this by adding more connection mark rules. If the in-interface is LAN, then you can use PCC load balancing to mark new connections as wan1 or wan2. You can put connection mark rules in the output chain in order to force a specific output interface when the Mikrotik originates a connection (such as sending a RADIUS request, or sending an email notification, syslog message, etc)
Make sure that the connection marking rules all have “pass through” enabled, and the packet route-mark rules do not.
The four packet route-mark rules shown are the only such ones you’ll need. The logic is done by using connection marks because you only need to follow that logic once for each new connection. (The connection-mark=no-mark criteria ensures this)
ok
I’ll try and let you know … if I still need help I’ll know because you are so gentili..un other info how do I make an autoswitch between the two gateways in case one of the connections I go down ? I was told taking a ping ip for example google DNS 8.8.8.8
The logic is done by using connection marks because you only need to follow that logic once for each new connection. (The connection-mark=no-mark criteria ensures this)
Never thought about that… Is that better than using connection-state=new?
I’d imagine that performance-wise, using connection state vs. connection marked/unmarked state are pretty close to the same. I think that logically, it’s more sound to use connection mark as your criteria, because it’s unmarked connections you’re looking for. I’ve seen some PCC configurations that only mark routing marks on packets that arrive on the LAN interface, for instance - which is fine, but has subtly different characteristics depending on how you built the logic of your configuration.
Same here with connection marking - it’s possible that you might have an unmarked connection even after the first packet has been replied to… at which point the connection state is no longer ‘new’ so if the connection is unmarked and you want to mark it, then state will no longer catch this.
It’s tiny little differences in logic like this which lead to bugs in software, right? If you assume that marked state is going to always match connection state - if it’s ever not the case, it can cause unforeseen behavior… so it’s always better to base your tests on the same thing you’re working with - in this case, connection marks.
The best way to enhance performance would be to make one rule that checks connection-mark = none, and if so, jump into a custom chain to classify the connection. The vast majority of packets are going to be in marked connections, so wasting only one check per packet is going to be a big boost instead of 5 or 6 checks per packet.
Thanks! The more I work with ROS, the clearer is for me that ROS is a matter of knowing networking, and “use your mind” along with ROS flexibility to solve any task 
I’m experiencing some packet marking oddities I cannot find any explanation for. I think you surely could point me in the right direction…
I made the configuration as below but when I enable the route does not go on the Internet , or rather when I enable the routing mark on gateways
/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark \
in-interface=ether1-WiFast new-connection-mark=wan1
add action=mark-connection chain=prerouting connection-mark=no-mark \
in-interface=ether2-loop.argiturismo new-connection-mark=wan2
add action=mark-routing chain=prerouting connection-mark=wan1 \
new-routing-mark=wan1
add action=mark-routing chain=prerouting connection-mark=wan2 \
new-routing-mark=wan2
add action=mark-routing chain=output connection-mark=wan1 new-routing-mark=\
wan1
add action=mark-routing chain=output connection-mark=wan2 new-routing-mark=\
wan2
/ip route
add distance=1 gateway=192.168.1.1 routing-mark=wan1
add distance=1 gateway=192.168.2.1 routing-mark=wan2
I forgot to point out that you also need to add local routes for the two WAN networks into the other routing tables.
dst=192.168.1.0/24 gateway=ether1 routing-mark=wan1
dst=192.168.2.0/24 gateway=ether2 routing-mark=wan1
dst=192.168.1.0/24 gateway=ether1 routing-mark=wan2
dst=192.168.2.0/24 gateway=ether2 routing-mark=wan2
If you don’t add these, then the next-hop address of the marked routing tables will be unreachable, so the default GW routes will be inactive. You can get away with adding ether1 to wan1 and ether2 to wan2, but if you’re also looking for failover, you’ll need those routes in both tables so why not add them now, right?
forgive me but adding these rules works also fail ?
Make sure your NAT rules are not failing to work properly.
NAT is really simple, though:
/ip firewall nat
chain=srcnat out-interface=ether1-WiFast action=masquerade
chain=srcnat out-interface=ether2-loop.argiturismo action=masquerade
You might also want to add to the output chain of mangle table (before the mark-routing rules):
/ip firewall mangle
chain=output src-address=ip.of.wan1 action=mark-connection connection-mark=wan1
Finally - make sure all of the action=mark-connection rules have “pass through” = yes and all of the action=mark-routing has passthrough = no.
I need other information , I have a hotel with two ADSL , one for the office and one for guests , both are connected to a 2011 , I would like the guest network 10.5.50.0/24 come out of the gw 192.168 . 2.1 and the office network 192.168.3.0/24 from 192.168.1.1 ,
I understand your design. This is a very very common question on these forums. (I’ve probably participated in at least a dozen discussions on policy-based routing in the last month)
My NAT comment is that the NAT rules are not complicated for this configuration.
Just make two rules which always masquerade when going out each DSL connection. The NAT rule doesn’t care WHO is trying to go that way - it’s not the NAT table’s job to worry about that. If a packet goes out dsl1, then it should have a dsl1 source IP. Period. End of story. No exceptions. The same is true for dsl2 (and dsl3, dsl4, etc).
Honestly, if this is complicated and not working, then the obviously simple solution is to just put in a second router for the guests. That’s an EASY configuration and doesn’t require all of this packet mangling / marking stuff.