Not to a bunch of MT customers, including myself, trying to accomplish load balancing with fail-over. To us it’s a flaw. So at the end of the day, it must be changed from being a showstopping-flaw-feature to being a … useful feature. Or at least a way to compensate for it must be CLEAR and straightforward to customers.
The router is just doing what you tell it. If you aren’t marking connections, marking packets, and then marking routing you’re going to miss things. A connection is only the beginning of a connection, not everything included within it.
I thought the marking I am trying to use is according to MikroTik RouterOS manual. It will be just the beginning when the connection-state=new matcher is used. Or do you mean that it misses “related” connections?
Pretend your a packet, and you get thrown into the ToADSL2 table.
There is no such routing table in this entire topic, unless you are saying that the routing-mark === “a routing table” ?
You cannot see anything but whats in that table, which means you only have a way to talk to your pppoe modem. Okay, suppose you need to talk back to the network you came from for any number of reasons, including ICMP messages, etc.
ICMP messages are originating from the router itself. Packet do not talk to anything. Routers and hosts do, connections do. Maybe you mean that when an ICMP message is generated by the router, it must also be directed accordingly, taking into account, the route the packet that caused the generation of the ICMP message, is traveling? Can this be accomplished with connection-state=related? And how? (by the way, connection-state is found only in http://www.mikrotik.com/testdocs/ros/3.0/qos/mangle.php )
Oh, that’s not in your routing table, so you fall thru to the main table. Routing tables work just like firewall chains, if something isn’t in the routing table your in, you fall back to the main table. You use the /ip route rules chain to order these things and possibly prevent the fallback to main.
Can you please point me to an thorough example of /ip route rules ?
A side note, your nat masq rules should be specifying an output interface, one for each. You don’t want to masquerade all traffic no matter what if it has that source range, only when it leaves and interface.
src-nat is in postrouting, where the routing decision has already been made, so it should correctly assign addresses.
Another side note: check-gateway=ping on a non-ip based route entry (interface routing) is probably not going to work, since it has no idea what to ping. It might work, but I’m guessing its not reliable.
I’m using only arp, I think it’s faster.
Your mangle rules are only mark routing for input chain and output chain, not prerouting or forwarding chain. You have src-address=10.0.10.9 on the prerouting mangle chain.
That is correct. And it should be correct according to manual and facility order of RouterOS.
In the end, I highly doubt the packets are leaking out because of some bug, it’s most likely improper setup. If you post more details we will help you fix it.
It is not a bug. It is a major mistake in software design. And I am currently trying my best, with your help, to work around it.
Thank you.
Regards.
And how can I solve all problems, like ICMP messages, related connections, connections coming from the internet to the router itself, packet leakage… etc. ?
Cool.