The problem is I cant connect to rouberbourd via winbox from WAN2 & WAN3 & WAN4
Only WAN1 works
If I disable WAN1 Route, I can connect to WAN2
And if I disable WAN1 & WAN2 Route, I can connect to WAN3
and if disable WAN1 & WAN2 & WAN3 Route, I cant connect to WAN4
I need to able to connect to any WAN IP via winbox not must disable Routes to another work.
That doesn’t prevent the Mikrotik from choosing the route for the response packets among all the default routes up to their
distance
parameter if none of the interfaces is down. And by
distance
, WAN1 always wins.
So as I’ve said, you have to
connection-mark, in ****
chain=prerouting
of
/ip firewall mangle
, the incoming connections via each interface with a
new-connection-mark
value corresponding to that interface,
translate these connection marks to routing marks in ****
chain=output
of
/ip firewall mangle
.
This way, each incoming connection will “remember” its interface by means of the connection mark, and choose the route via that interface for response packets up to the routing mark assigned based on the connection mark.
The connection-mark-to-routing-mark translation rules in ****
chain=prerouting
do not affect locally originated packets because locally originated packets do not pass that chain. This picture says it all.
Hello sindy
i have change from NTH to PCC for some Internet issues
and added the code you have told me
but its not work please take alook for my config
If I may, I am not sure if the passthrough on connection marking was intentionally set to no or if it was a copy / paste error, will wait for @sindy’s response to that, but to me it does not make sense as it will then never mark the routing, so below my suggestion to try:
@CZFan, what I’ve posted was an add-on to existing rules, serving two separate purposes:
the first four rules are there to ensure that connections initiated by packets coming from outside, via one of the WAN interfaces, will be marked to use that WAN interface. Therefore, passthrough=yes is not necessary, because packets coming in via WAN typically do not need to be routing-marked, so we may stop mangling packets received from WAN immediately after connection-marking them. And the passthrough value is only relevant if the rule matches - if it doesn’t, the next rule is always processed.
the second four rules are there to assign a routing mark (based on connection mark) to packets sent by Mikrotik itself. Also here passthrough=no is fine, because once you assign one routing mark, there is no point in scanning further rules - unless something got wrong, none of them will match anyway.
But if there are some other things to do in the mangle table (like packet marking for QoS), of course you have to adjust the approach accordingly. However, if that was the case, I’d probably organize the distinct tasks into dedicated chains, so the first rule in chain=prerouting would call a “connection&routing marking” chain, and when processing of that chain would finish, the processing in chain=prerouting would continue (by assigning the packet marks for QoS). The passthrough=no in a rule in a called chain means that if the rule matches, only the rest of that called chain is skipped, and processing continues by the next rule in the calling chain.
Now let me have a look what is wrong with the complete configuration.
@eslamxboss, in your original post you were using connection marks line1 to line4, so I’ve given you the additional rules in accord with that nameset.
However, in the last configuration export, you use connection marks ISP1_conn to ISP4_conn in the rules which assign them based on pcc and in the rules which translate them to routing marks, but you haven’t modified accordingly the rules you’ve got from me.
The trick is that the all connections which should use WAN1 must have the same connection mark (regardless whether ISP1_conn or line1, but the same one) regardless whether WAN1 was chosen for them by the pcc rule if the initial packet came from LAN or by the fact that the initial packet of the connection came in via WAN1 from outside.
Similarly, “my” rules in chain=output must assign the same routing marks up to the same connection marks as your rules in chain=prerouting. So replace lineX by ISPX_conn where they are used as conection marks, and replace lineX by to_ISPX where they are used as routing marks, and you’ll be good.
Connection marks, routing marks and packet marks use different namespaces, so a string used as a connection mark doesn’t interfere with the same string used as routing mark. You need the rules to translate the former into the latter.
Other than that, you use four rules differing only by dst-address=so.me.sub.net/24, but those subnets are adjacent to each other. You can merge that into a single rule with dst-address=192.168.1.0-192.168.4.255.
Just to confirm, the OP was talking about accessing the routerboard from outside the router (ie on the internet) and not internal access. I thought the reverse and was wondering why are we monkeying with in-interface WAN rules.
Would it be better or easier to simply use VPN to access the router and then use WINBOX (from the inside).
If so I guess the problem remains, of the ability to vpn in on any of the WANS??
Exactly. The transport connection of a VPN is a connection just like any other, so you need to make sure that it uses the WAN through which it was established for both directions.
