I've discovered a bug that causes masquerading to not work properly. It happens when the NAT rule to-ports property has been set and the action property is masquerade. In this situation the to-ports is used when it should be ignored by masquerading. I.e. masquerading should use the original port. This causes problems when a client wants to do sequential connections, each with a different source port, but the same destination port.

I managed to encounter this bug when I created a nat masquerade rule by copying an existing dst-nat rule and then changing the copy to have a masquerade action. The to-ports property was still set the same as the original dst-nat rule (and then used when doing the masquerade translations). BTW, both winbox and webfig show the To Ports property to be empty if the action is masquerade. It wasn't until I started packet sniffing that I was able to see that masquerading had replaced the original port with the to-port that had been used in the original dst-nat rule.

Configuration : RouterBoard 450G, Firmware 2.29. RouterOS 5.11

you sure this is a bug? i think you should be allowed to masq ports on the way out to a specific range, ie; 40000-65535 only ... the default is 0-65535 and you can just limit the src range to something smaller if you want.

I've discovered a bug that causes masquerading to not work properly. It happens when the NAT rule to-ports property has been set and the action property is masquerade. In this situation the to-ports is used when it should be ignored by masquerading. I.e. masquerading should use the original port. This causes problems when a client wants to do sequential connections, each with a different source port, but the same destination port.

I managed to encounter this bug when I created a nat masquerade rule by copying an existing dst-nat rule and then changing the copy to have a masquerade action. The to-ports property was still set the same as the original dst-nat rule (and then used when doing the masquerade translations). BTW, both winbox and webfig show the To Ports property to be empty if the action is masquerade. It wasn't until I started packet sniffing that I was able to see that masquerading had replaced the original port with the to-port that had been used in the original dst-nat rule.

Configuration : RouterBoard 450G, Firmware 2.29. RouterOS 5.11

The potential bug you found is definately a possiblity.

Try this, like I did, to see more: On the rule that you copied, and is now a masq rule with no to-ports listed... change it back to dst-nat and you will see that it STILL HAS YOUR OLD DST-NAT TO-PORT VALUES LISTED!!! So, the masq rule is definately saving the to-ports even though it is not showing them.

If this is reproducible, please send all of this information to support@mikrotik.com

you sure this is a bug? i think you should be allowed to masq ports on the way out to a specific range, ie; 40000-65535 only ... the default is 0-65535 and you can just limit the src range to something smaller if you want.

Not sure that I agree. But, then, I'm not expert enough to disagree. But, the documentation at http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT states that to-ports is "Applicable if action is dst-nat, redirect, netmap, same, src-nat".

The potential bug you found is definately a possiblity.

Try this, like I did, to see more: On the rule that you copied, and is now a masq rule with no to-ports listed... change it back to dst-nat and you will see that it STILL HAS YOUR OLD DST-NAT TO-PORT VALUES LISTED!!! So, the masq rule is definately saving the to-ports even though it is not showing them.

If this is reproducible, please send all of this information to support@mikrotik.com

I had already done this, so I guess it's reproducible I'll send the info to support@mikrotik.com

I think the bug isn't that the to-port is being stored. Rather, I think it's that it is being used when the packets are being translated under the rule.

The potential bug you found is definately a possiblity.

Try this, like I did, to see more: On the rule that you copied, and is now a masq rule with no to-ports listed... change it back to dst-nat and you will see that it STILL HAS YOUR OLD DST-NAT TO-PORT VALUES LISTED!!! So, the masq rule is definately saving the to-ports even though it is not showing them.

If this is reproducible, please send all of this information to support@mikrotik.com

I had already done this, so I guess it's reproducible I'll send the info to support@mikrotik.com

I think the bug isn't that the to-port is being stored. Rather, I think it's that it is being used when the packets are being translated under the rule.

Part of the bug is probably that it is being stored. It shouldn't be stored... and if it wasn't stored, then it couldn't be used. Regardless, this is something that only a Mikotik developer can actually see under the hood.

I don't agree with your interpretation of masquerade action. Masq action, IMHO, is a src-nat which simply picks the to-address based on the pref-src in the route chosen for the traffic. Contrast that with the src-nat action which uses the address specified in the rule. With both actions, if you have entered a value in to-ports, then the port will get changed as well.

If you are saying that you remove the to-ports parameter, this can be verified with the command, and the ports are still being changed when there is no collision with an in-use port, then it would be a bug.

I don't agree with your interpretation of masquerade action. Masq action, IMHO, is a src-nat which simply picks the to-address based on the pref-src in the route chosen for the traffic. Contrast that with the src-nat action which uses the address specified in the rule. With both actions, if you have entered a value in to-ports, then the port will get changed as well.

If you are saying that you remove the to-ports parameter, this can be verified with the

Code: Select all

/ip firewall nat export

command, and the ports are still being changed when there is no collision with an in-use port, then it would be a bug.

I agree with your interpretation of how masquerade works, but I don't think you see the bug.

In Mikrotik: When you choose MASQUERADE, there is NO option to specify any to-ports. The option dissappears. When you change back to dst-nat, then the "to-port" option returns. So, to enter a to-port, you have to choose dst-nat, then enter the port, then change to masquerade and the to-port dissappears in winbox and in the terminal export.

However, if you change back to dst-nat, the ports are still listed... this means that the ports are saved even though they do not show up and it is impossible to enter or change them after masquerade is chosen.

BUG = if the to-ports are not an option in masquerade, then they should not be used in masquerade. So, Mikrotik should either make to-ports an actual option in masquerade, or don't use them at all in masquerade.

Setup this rule:
Now, change from dstnat to srcnat, and change from dst-nat to masquerade, CHANGING NOTHING ELSE
Notice the to-ports are gone, they are not an option at all. That is fine.

Now, change from srcnat to dstnat, and change from masquerade to dst-nat, CHANGING NOTHING ELSE
Look at the to-ports there!!! They came back, proving that they were saved with the masquerade but not shown. They should have been deleted completely since they don't show up... but there they are.

And since they are saved with the masq rule, unseen, it is very possible that the masquerade rule is actually using them without anyway to see it in the rule itself.

If you delete the "corrupt" rule and re-add a completely new masq NAT rule: the dst-ports are not changed on the outbound traffic?

If you delete the "corrupt" rule and re-add a completely new masq NAT rule:

Code: Select all

/ip firewall nat export:
add action=masquerade chain=srcnat disabled=no protocol=tcp src-address=2.2.2.2

the dst-ports are not changed on the outbound traffic?

Correct, with a new rule, it works as expected. By changing a rule that has to-ports to a rule that does not, I can sometimes reproduce this error, and must delete and recreate a new non-corrupt rule.

probably winbox caching the info ... i doubt its stored in the routeros config anywhere.

probably winbox caching the info ... i doubt its stored in the routeros config anywhere.

Definately NOT winbox caching it. I can go to another computer, change the masquerade to dst-nat, and the old values are STILL there... on another computer.

They are definately stored in the routeros config.

I think that those value fields are simply hidden when you choose masquerade, but they are always there and saving the values.

We'll have to wait and see what the developers had in mind. But, I'm guessing that their intent is that to-ports should be stored if it were ever specified and would then be used if it were appropriate. (It's a bug that to-ports are used for masquerading). This is the way I would design the system. The reason is that when developing a rule the user is likely to try different actions, some requiring to-ports, and some where to-ports isn't relevant. When to-ports is relevant it's probably the same port and, therefore, needs to be remembered. It's a user convenience issue.

Another way of looking at it is that it's a smart method to provide a default for a property. The user interface has many, many examples where this strategy is used. E.g. If the Dst port of a Nat rule has ever been specified then that value is the default if the Dst port is turned off and then back on.