I know that similar situation is discussed on several threads here, and I have checked many of them, but still I do not have the solution to my problem. Imagine I have two wan connections and mangling set like this:
/ip firewall mangle
add action=mark-connection chain=input disabled=no in-interface=
ether1-isp1 new-connection-mark=isp1-in passthrough=yes
add action=mark-routing chain=output connection-mark=isp1-in disabled=no
new-routing-mark=isp1-out passthrough=no
add action=mark-connection chain=input disabled=no in-interface=
ether2-isp2 new-connection-mark=isp2-in passthrough=yes
add action=mark-routing chain=output connection-mark=isp2-in disabled=no
new-routing-mark=isp2-out passthrough=no
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=[GW IP of ISP1 HERE]
routing-mark=isp1-out scope=30 target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=[GW IP of ISP2 HERE]
routing-mark=isp2-out scope=30 target-scope=10(source: http://home.swkls.org/mikrotik-dual-wan-routing-packet-flow/
It works perfectly in order to respond to the right WAN if service on router is accessed. But the problem is, when dst-nat port forwarding is used for accessing server in the inner network behind NAT (src-nat masquerade). In this case, only from the first default wan the connection is possible. Because I did not managed to correctly mangle the forwarded connection.
Of course, the outgouing default WANs are added to routing also with connection-mark:
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=[GW IP of ISP1 HERE] routing-mark=isp1-out scope=30 target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=[GW IP of ISP2 HERE] routing-mark=isp2-out scope=30 target-scope=10besides the default routes for not marked connections (and with higher distances).
Adding a prerouting rule like this
/ip firewall mangle
add action=mark-connection chain=prerouting disabled=no in-interface=ether2-isp2 new-connection-mark=isp2-in passthrough=yesdid not helped. It seems in connection tracking that it mangles more traffic, but not all and without expected effect. The connections initiated outside WAN2 cannot be successfully made into a device in LAN even the connections initiated outside WAN1 work.
I am sure that there is someone that succeeded with this. In this case, please, share the way how to access the in-network resource by both WANs at the same moment.
Input and output chains are only for router. So even if you add prerouting rule, it still won't help you, because you set routing mark only for router's own output.
My working example with main and backup connections (simplified from larger config, so I hope I did not accidentally delete too much):
/ip firewall mangle
mark incoming connections (same rules cover both traffic for router and traffic forwarded to LAN)
Hello,
thank you for your hint, it helped me. The “jump” and “return” rules was invalid until first “routing” rule was added. Cool.
I have switched off my “input” and “output” rules as I considered them not necessary.
I guess, I do not need your last two rules so I did not used them. Did I right or not?
Why also connections originated from internal network (typically browsing the web from client stations) are also subject to connection marking? I think, it is not necessary. I would like to keep them unmarked to be able easily distinguish real input traffic from WANs from the trafic originated from LAN. Hope it is not silly.
Are you sure that the two “return” rules should be defined by dst-address? Why? I kept them so, the first is quite a bit used, the second had not any hit, so far.
Anyway, cannot it be done more easy without jumping/return rules? - just asking, no complaints…
Thank you very much again. Going to give you karma.
You original input rules are fully replaced by rules at lines 3-6. Output rules are basically the same, they are just in different chain now, lines 15-18, shared with both output and forward.
If you mean lines 20-23, it’s possible that you don’t need them. Their purpose is to force LAN clients to use selected ISP. Normally it’s primary one and when it fails (can be checked by Netwatch), the backup rule is enabled and all new outgoing connections will go through backup ISP.
I don’t think routing sticks by itself, so you need all connections marked, to ensure their consistent routing through same ISP. Anyone correct me if I’m wrong.
But you can use different marks (isp1in, isp1out, isp2in, isp2out). For *in marks there are rules 3-6. And *out marks would have to be set in routing chain before marking routing (before line 12) and with passthrough=yes.
Currently it works a little strange, because outgoing LAN connections are not marked right from the beginning. The first packet just goes out unmarked. It’s the first reply packet that makes the connection marked (catched by lines 3-6).
As I wrote, this is only part of larger config. The real thing has other rules in routing chain, dealing with another routed public subnet and few exceptions to force use of specific ISP for some destinations. The idea of return rules is to save router some work. Why try to match several other rules, when right at the beginning is clear that some packets won’t go out through any ISP. That’s what return rules (lines 12-13) are for. I admit that the effect is not exactly backed up by accurate measuring. And of course line 13 depend on existing address list, that’s why yours can’t have any hit.
I’m sure that jumping can be avoided, if you want. But I like it, because generally it saves rules and helps to avoid future mistakes. When you need to change something, it’s safer to change only one thing instead of several duplicates, that way you can’t miss any.
Hi,
used Sob’s config and in addition I want to route traffic from specific internal IP through backup line.
I put this mangle rule before line 7 which marked connection proper (conn_backup), but leave routing throught primary line:
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=LAN new-connection-mark=conn_backup src-address-list=to_backup
Modification passthrough value to yes cause proper marking and routing, but have huge impact to jitter (>150ms) and in fact unusable speed:
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=LAN new-connection-mark=conn_backup passthrough=yes src-address-list=to_backup
The way you describe it it seems to me that you’ve kept the action=fasttrack-connection rule in /ip firewall filter in place unmodified, which causes only every N-th packet to be routing-marked, whereas the other packets bypass the mangle, thus take the default route and are therefore dropped by the recipient as they come from a different address than the initial packet of the connection.
If my guess is correct, you will have the same problem if your primary uplink goes down. In such case, you would have to add a condition connection-mark=no-mark to the action=fasttrack-connection rule.