My friends when using action=masqerade the src-addr is not chosen properly. The rule did not work and the router did not send the packet out the proper interface.

SOMEONE FROM MT DEVS PLEASE EXPLAIN EXACTLY

EXACTLY

how that decision is made!!!

I don't want to hear any excuses! Only the truth!!!

Can you post the exact masquerade rule? We generally specify the network under src-address like so:


chain=srcnat action=masquerade src-address=10.59.0.0/24 out-interface=WAN

yes what you do works 100% but when specified just

"masquerade"

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

sounds like configuration issues.

why are your src-nat dst port 8291 ?

What happens if you add a source address like the below:


chain=src-nat dst-address=A src-address=B dst-port=8291 protocol=tcp action=masquerade

nat and routing are completely separated from each other... connection tracking knows nothing about interfaces or routes. you have to make sure you send the traffic the right way, its not automatic. you say its a bug in 4.6, so with the _exact_ same configuration it works in previous versions?

Mbybe it works 99.99% of the time so a lot of people thought its the right way to do it.

But then a condition happened. for exmple the cable at thte ETH interface where the packets should go out of - got unplugged. And then plugged in again.

I can't use src-addr in my NAT rules, those are dynamic too often.

I think this problem exist in all versions.


The routing decision should decide where the packet goes. I shouldnt need to route mark it etc. myself.

NetworkPro - i can sell to you working MASQ rule. (the similar rule work on many routers with no problem)

You did not work 10 years to develop that NAT rule. Do you really have a fix for this problem or are you just playing like a kiddy?

You are right, i did not work with MT 10 years, only 7 years, and this NAT rule setup on my routers only 7 years (from version 2.7 to version 5.0) and on all version its works fine

OK, lets get back to actual topic

NetworkPro - could you, please, give us exact network structure and IP addresses of the problematic setup we can try to go trough it and see where is the problem. At this point there is not enough information. also add description of expected and actual result of these rules.

yes what you do works 100% but when specified just

"masquerade"

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

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.

MT_X(B)---cable---(A)MT_Y

(B) and (A) are the interfaces with some addresses

the nat rules sit in MT_X

the goal is to connect Through MT_X and get to MT_Y, with masq, so that MT_Y thinks that you are coming from address B.

Because MT_Y has no config yet. It has no default route.

This is elementary stuff, yes?

Just re-created your configuration and it worked like a charm.

chain=dst-nat dst-address=11.11.11.11 dst-port=8292 protocol=tcp action=dst-nat to-address=10.0.0.253 to-ports=8291
_optional_(chain=src-nat dst-address=A dst-port=8291 protocol=tcp action=log)
chain=src-nat src-address=10.0.0.0/24 action=masquerade

With this config I can connect from outside to my public IP: 11.11.11.11:8292 and get to inner router 10.0.0.253:8291
With this config I can connect from local network to my public IP: 11.11.11.11:8292 and get to inner router 10.0.0.253:8291


Routing - default route to Intenet only.

Just read your first post:

Take a look at: http://wiki.mikrotik.com/wiki/Manual:Packet_Flow


Dst-nat--->Routing Decision--> Src-nat

So dst-nat will change dst address and then based on new dst address "Routing Decision" will determine what gateway to use (so what interface will be out-interface). From this moment on you can't change outgoing interface, it is set in stone. So src-nat have nothing to do with routing - it just make cosmetic work.

I know mate. I eat the diagrams for breakfast lunch and dinner almost every day. I mumble in my sleep how the packets go around

So in my case, I sniffed with sniffer and the packets did not go out that interface. So Routing Decision must have sent them somewhere. Maybe they were teleported to the future!

As I said, Then I changed from action=masq to action=src-nat to-address=B and it magically started working again

And still all around the world in MT routers I still have rules just with action=masq that still work. So something must have happened to that particular rule. And by the way I think this problem happened before too, because I had troulbe logging in other stuff through such rules before...

And on all attempts the rules count packets so they appear working. But the sniffer revealed the truth.

BTW - why do you need masquerade at all? - dst-nat rule will ensure reverse action for all answer packets anyway.

what ? No it will not. If I did not have masq, the inner router would see a packet coming from an Internet IP. With no route to it, the connection would not establish. The masq rule makes the inner router see the packet as it comes from the other router right next to it, to which it has a directly connected route. Yes?

/export ip route
/export ip address
/export ip firewall
after that we can see why its happens

I'm not sure if this is completely related, but... would this be the same?
/ip firewall nat add action=masquerade chain=src-nat disabled=no out-interface=WAN

I have no problems with this for the life of my RouterOS.

NetworkPro,

I think the missing data would your packet capture. On Linux, you can use tcpdump to get a readable output. Could you post it here?

I'm just trying to understand the problem better.

Its just a router that routes traffic from the nstreme wlan1 to the wlan2 and the other rtr is connected on the eth1

/ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.6.9 scope=30 target-scope=10
add disabled=no distance=1 dst-address=192.168.6.0/30 gateway=192.168.6.6 scope=30 target-scope=10
add comment="" disabled=no distance=1 dst-address=192.168.6.12/30 gateway=192.168.6.9 scope=30 target-scope=10

/ip address
add address=192.168.6.5/30 broadcast=192.168.6.7 comment="" disabled=no interface=wlan2 network=192.168.6.4
add address=192.168.6.10/30 broadcast=192.168.6.11 comment="" disabled=no interface=wlan1 network=192.168.6.8
add address=10.234.56.8/24 broadcast=10.234.56.255 comment="" disabled=no interface=ether1 network=10.234.56.0

/ip firewall connection tracking
set enabled=yes
/ip firewall nat
add action=dst-nat chain=dstnat comment="" disabled=no dst-port=8292 protocol=tcp to-addresses=10.234.56.7 to-ports=8291
add action=dst-nat chain=dstnat comment="" disabled=no dst-port=8293 protocol=tcp to-addresses=10.234.56.7 to-ports=8292
add action=src-nat chain=srcnat comment="" disabled=no dst-address=10.234.56.7 dst-port=8291-8292 protocol=tcp to-addresses=10.234.56.8

The last line was action=masquerade when the prob occured..


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..

Forget my last post, I understand now.

If you unplug, then plug in ether1 cable, can you ping out ether1 from a device behind your router? If so, the routing itself should be working. I'm wondering if it might be a problem with the src-nat routing decision, not detecting the down/up route state? (Of course, this is your post topic).

But to test, this only happens at random times, so if I were to test, I may not see your exact results?

[xxx@cip-office] /ip route cache> print
cache-size: 11051
max-cache-size: 65536

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.

I will assume that packets to these ports will come from either wlan1 and wlan2. Only a suggestion... may help on troubleshooting.

/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

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:

add action=masquerade chain=srcnat comment="" disabled=no out-interface=ether1 dst-address=10.234.56.7 dst-port=8291-8292 protocol=tcp

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...

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

are any of the interfaces on a bridge?

No bridges.

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..

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...

It was unplugged. Then it was plugged back in. All tests were performed with a plugged in cable haha. What do you think ? hahaha.

It was unplugged. Then it was plugged back in. All tests were performed with a plugged in cable haha. What do you think ? hahaha.

This sounds as funny as the "funny bone". It is only funny when it happens to somebody else.
If it was unplugged at any time, it is possible that conntrack follows that change for 10 minutes.

conntrack ? that's for packets from the same TCP connection.

I tried to create new TCP connections. I closed WinBox and tried to connect again, multiple times.

So the problems is somewhere in Routing Decision. Maybe.

When you tried the "action=masquerade" rule, did it look like this?
/ip firewall nat
add chain=srcnat action=masquerade out-interface=wlan1

Are you really a surfer?

It looked like this: http://forum.mikrotik.com/viewtopic.php ... 91#p204591

While I look at that, you may Google "surfer tim miramar beach". Yes, blood in the water....

ADD. I see you tried this
/ip firewall nat
add chain=srcnat action=masquerade

That won't do it. It needs an out-interface to function in your setup.

That should be selected in Routing Decision. It usually is. ?

This you ?

answer for my last question

That pic is not me, but it is a good picture! If you only knew how many times that happens and nobody sees it, not even the surfer. I try to avoid confrontations with sharks, and encourage others to do the same.

Not sure what you mean by selected in routing (/ip route). This is a nat (/ip firewall nat). You only want a masquerade applied to packets going out the wan interface. In your case, that is wlan1.

ADD: I think that pic is altered. In that stage of a great white shark attack (that is a great white), the eyes would be covered and the mouth would be wide open.

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

I "drill in" and thats an expression not for your sore tooth but as in - these NAT rules get me in through 3 or 4 routers. The same rules. And guess what. The 5th one failed. LOL.

[xxx@cip-office] /ip route cache> print
cache-size: 11051
max-cache-size: 65536

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.

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?

Hmmm. Maybe if I capture some WinBox connection attempts...

again, conntrack knows NOTHING about routes. If the router (yes, its a router) caches a route that it prevously used, it is only caching the destination and the next hop... not anything about connections. So, even though you have a route in the route table, dont assume it isnt cached and using another value. I wish there was a configurable max there so you could lower it, or flush it.

AAaghh hah. I see what you mean now.

Wow. Thanks for the clarification mate.

p.s. but hey? This sounds like a bug.

A directly connected route should wait 10 minutes before it is available?

I'm lost again. Maybe tomorrow. Its late here.


P.S.2 And I did not wait 10 mins , I changed the rule to src-nat with a to-addreess and it worked right away. So.. ?

sorry, I'm just skimming throuth the topic, but...

as far as I understand, 'action=masquerade' selects Pref. Source as to-addresses from the route, so if route is cached together with Pref. Source... =)

Somebody correct me if I am wrong, but if you use

/ip firewall nat
add chain=srcnat action=masquerade

that will masquerade all interfaces. Even your localnets. So when you request a website with ip address xx.xx.xx.xx from a client computer on ether1 (this is not the wan in your setup), your source address is maqueraded out wlan1 (the wan interface) as 192.168.6.10, correct? From there to the next masquerade, your packets are from 192.168.6.10 destined for xx.xx.xx.xx.

OK, packets come back from xx.xx.xx.xx destined for client on ether1. Packet source shows xx.xx.xx.xx, correct? Well, it does until it runs into your masquerade. Then that masquerade rule, now applied to all interfaces, will srcnat the packets, showing the new source as 10.234.56.8 (pref-src for ether1). But the client is not expecting anything from 10.234.56.8.

If this is not how this works, please correct me. Maybe I don't understand this as well as I thought.

no, it's not true

look at Packet Flow diagram - SRC-NAT is even after Mangle Postrouting, and it knows nothing about in-interface

and about packets coming back: NAT only works on new connections. you cannot NAT established connections

Thanks, Chupaka. Then this rule in his setup would have no effect? (I'll make that a question)

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether1

Remember, ether1 for him is localnet. wlan1 is the gateway.

ADD: No answer required. You are correct. No effect. Just checked it. Appears to be applied only to connection-state=new.

@NetworkPro Have you checked "/ip firewall connection" when this is happening? It will show the connections, states, and timeouts.