Thanks for the export.
It turns out that either this configuration is not supported by MikroTik or there is a bug.
According to the Packet Flow Diagram, if I understand it correctly, dst-nat
should be able to detect the packet/connection marks since mangle prerouting
is before dst-nat
.
But after some tests of my own I got stuck the same as you did.
While mangle/filter can match the marked packets (or even without marking, but by directly using the L7 filter on the rules) on nat it simply does not match any packets.
There are also various relevant threads on the MikroTik forums, which none seem to have found a solution.
http://forum.mikrotik.com/viewtopic.php?f=2&t=83129
http://forum.mikrotik.com/viewtopic.php?f=2&t=73856
http://forum.mikrotik.com/viewtopic.php?f=13&t=62152
One guy mentions a solution by using the WebProxy of MikroTik, which I personally wouldn't use since it will change the source IP address to the IP of MikroTik and thus the webservers will log all requests with the same IP instead of the real visitors' IPs.
I can think of two other solutions but are not that straightforward.
Solution 1:
If you are using version 5.x of MikroTik there is an ISO image that will patch MikroTik and add a minimal debian distro on top (or bellow) it.
Which then you can use to install HAproxy or any other reverse proxy you like to accomplish what you need properly (HAproxy or any other reverse proxy is the correct way to do this as others have already mentioned)
Solution 2:
Another approach is to create a metarouter (if you run MikroTik on a routerboard, you have enough free RAM and you don't use nstreme) and load an openwrt image on it.
On which you can then install a reverse proxy of your liking to accomplish the task.
Most likely not a solution:
Of course you could also send a support ticket to MikroTik to confirm or (most likely) deny that there is a bug on NAT with L7 packet marking. But I wouldn't expect much from their support. Most of the time will not help you at all. Their default strategy is that everyone is stupid and the problem is always on the users' configuration and not on MikroTik itself...
It would be nice to be able to handle this task on the router itself. It's suitable for constrained environments where putting yet another machine to do the reverse proxy is not an option. Though I wouldn't use this method (even if it worked) on a production environment.
Layer 7 filter is quite slow and heavy for the router.
Update:
I just saw that you are using RB2011, so the ISO/debian solution won't work for you (it's only for x86).
If you are not using nstreme (I guess not) then your only bet is by using a metarouter with openwrt to do the reverse proxy stuff for you.
Best Answer
You can create 2 additional NAT rules for TCP/UDP. Set the first to match TCP packets going out to WAN and set the action to
src-nat
; Then specify the correct public address and port range. Do the same for UDP, then have the standard masquerade rule underneath to catch anything else.It will not use open ports for NAT, and while I don't know the exact port range it uses, it will certainly not use low port numbers like 22/23. Not sure if it's clever enough to automatically avoid ports you have
dst-nat
rules set up for though.