And when I changed the rule to action=src-nat to-address=B - it worked, the packet got ot the interface. Where as previously the rules counted the packets. BUT sniffer did not catch anything on the interface. They did not come out that interface. And the other night these rulese were werking with "masqerade" its how I always did it and how it was always working. But that day I saw this problem and I saw that something is wrong with maybe Routing Decision.yes what you do works 100% but when specified just
it stops working in certain conditions
in which exact conditions developers could say.
stops working = nats to a not correct not working src-addr.
chain=dst-nat dst-port=8292 protocol=tcp action=dst-nat to-address=A to-ports=8291
chain=src-nat dst-address=A dst-port=8291 protocol=tcp action=masquerade
these are the rules that seem to masq with a wrong src-addr
when the problem happens
the rules count packets
but these packets never go out the right interface that the "Routing Decision" should point the packet to, becase of the dst-nat rule in prerouting
Here these packets will arrive the host 10.234.56.7 with YOUR HOST as source address. Since you are intended to masquerade it as 10.234.56.8, then I guess it will be sufficient:/ip firewall nat
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=192.168.6.5 dst-port=8292 protocol=tcp to-addresses=10.234.56.7 to-ports=8291
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=192.168.6.10 dst-port=8292 protocol=tcp to-addresses=10.234.56.7 to-ports=8291
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=192.168.6.5 dst-port=8293 protocol=tcp to-addresses=10.234.56.7 to-ports=8292
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=192.168.6.10 dst-port=8293 protocol=tcp to-addresses=10.234.56.7 to-ports=8292
When unplugging ether1 cable, It may will render your masquerade rule momentary invalid and the router will sent the packet back through default route. Worth a try? It may clear any associated cache I think...add action=masquerade chain=srcnat comment="" disabled=no out-interface=ether1 dst-address=10.234.56.7 dst-port=8291-8292 protocol=tcp
If you unplug the cable, any routes associated with that interface will become unreachable. The OS does not use unreachable routes. Just a thing it has...Maybe the problem occurs when the eth1 cable is unplugged and then plugged in again, the directly conencted route stops working and routing decision sends the packet somewhere..
This sounds as funny as the "funny bone". It is only funny when it happens to somebody else.It was unplugged. Then it was plugged back in. All tests were performed with a plugged in cable haha. What do you think ? hahaha.
answer for my last question
tell me, does you PC (from what you connect to problem router) know where is 10.234.56.7 ? i meen route know ?
Beacose you masquerade only to dst 10.234.56.7, bu dont masquerade 10.234.56.7 to other network including your PC.
add new rule in nat
/ip firewall nat add action=masquerade chain=srcnat comment="" disabled=no src-address=10.234.56.7
But how come it would use the old route. Could it mean? That WinBox connecting, does not properly tear down and establish a new TCP connection? So the conntrack could mistake the next packet, next connection being tried, as a part of the previous one? And treating those packets as if they ere from that preious conntrack etnry?[xxx@cip-office] /ip route cache> print
Next hops are cached, so you are right, if traffic was leaving ether1 and now it's unplugged, its possible it will cache another route, and even when ether1 comes back up it's using the old route. I think I read somewhere it was a 10 min cache maybe? This is somewhat new I believe, maybe around the same time ecmp was affected and pcc came out.