Hi there. So, I have two NAT rules for port forwarding, configured identically, one for accessing a machine via RDP (port 3389) and the other rule for accessing the same machine via FTP (port 21). The RDP rule works, the FTP one doesn’t. Winbox screenshot attached. Any clues? Thanks.
/export hide-sensitive file=anynameyouwish
The rule apparently works, since there are packets counting…
Are you sure the server is listening to the correct port ?
Or you don’t block it through the Firewall ( the to-ports port )?
FTP requires 2 ports. The command ports which is usually ports 21 and a data port. For active mode, the data port is usually port 20. For passive mode, the port is a random port (you can usually set a range inverter settings.) You will need to also forward the data port(s) depending on mode type used.
FTP is not very firewall friendly protocol, because it uses multiple connections. You can either configure everything properly, i.e. forward both control port and range of ports for data (passive mode) and configure server to use only those, or you can rely on connection tracking magic. The latter works only for plaintext unencrypted FTP, and by default only with standard port 21. I didn’t test which port it cares about when there’s NAT (original or changed one), but if it’s the original one, then this should help:
/ip firewall service-port set ftp ports=21,2121
I have only used on port in MT to forward FTP and it works fine. It may that MT does some more than I see.
add action=dst-nat chain=dstnat comment=“FTP → Server” dst-address-list=WAN-IP dst-port=21 log-prefix=ND_DE_FTP-Balder protocol=tcp to-addresses=192.168.233.32
Off topic: I’m new to this forum. Among the default settings in the profile is the one to not be notified on replies on my own posts. This is insanely stupid! Hence my late reply.
On topic: I know ftp uses multiple ports, but that is not the issue here. What I did was trying to telnet on the outside port 2121 and all I get is a timeout. There is no firewall involved in this case, the ISP’s router is configured with MikroTik’s IP as DMZ, that is, everything is forwarded to MikroTik.
The backend machine does listen on port 21 as I can telnet to it from the internal network.
This is a mater of simple port forwarding, doesn’t really have to do with the ftp protocol. I’m lost.
Here it is. Thanks for your time 
settings_p2121_to_p21.rsc (7.35 KB)
Your are missing /interface bridge vlan
Assuming you are sending the vlan to your AP, you still need
/interface bridge vlan
add bridge=BRIDGE-LAN tagged=BRIDGE-LAN,ether4 vlan-ids=172
DANGER, do not let any PLAIN IP access to your router!!!
add action=drop chain=input comment=“defconf: drop all coming from WAN”
in-interface-list=WAN log-prefix=DROP_ src-address-list=!Safe_IP
if its not encrypted its NOT SAFE!!!
Dont see anything else problematic as it pertains to port forwarding however I do not understand these ones… at least residing under NAT firewall rules.
More than likely it is fine/correct, I am not just not familiar to this example…
add action=add-src-to-address-list address-list=RDP-LOG address-list-timeout=
none-dynamic chain=dstnat dst-port=8012 protocol=tcp
add action=add-src-to-address-list address-list=FTP-LOG address-list-timeout=
none-dynamic chain=dstnat dst-port=2121 protocol=tcp
As for the FTP, ensure
a. you are putting in the right information to access the server (IP of router and expected incoming port)
xx.77.cc.33.ee**:**2121
b. there is not a local PC firewall rule blocking FTP traffic
c. Not familiar with FTP but I see it uses TCP protocol do you need to add a duplicate rule for udp?
d. Try using a different entry port 12121 perhaps 2121 is jinxed.
/ip firewall nat
…
add action=add-src-to-address-list address-list=FTP-LOG address-list-timeout=none-dynamic > chain=dstnat dst-port=2121 protocol=tcp
add action=dst-nat > chain=dstnat > comment=FTP > dst-port=2121 > in-interface-list=WAN > protocol=tcp > src-address-list=Safe_IP to-addresses=192.168.55.5 to-ports=21
Firewall rules (filter as well, not just nat) are evaluated from top to bottom and if any one matches, it’s executed. But rule traversal is done as well. So of the two rules quoted above, which match same packets (or rather, the first one will match more packets than the second one), only the first one is executed (add-src-to-address-list).
@mkx: Not all actions stop traversal and add-src-to-address-list is one of those.
It doesn’t look like anything in this config is stopping it. I’d check FTP server, even if it’s accessible from LAN, it doesn’t mean that it has to automatically allow access from elsewhere.
Hmm, (C1 - S0)
So sob it seems one can concude that passthrough (Stop Traversal decision) is not a function, I mistakenly thought, that is unique to ip firewall MANGLING.
(Probably because most of the passthrough rules I had seen have been done on Mangling!)
It appears the conclusion/take away is that RoS considers certain “Actions” as having specific functionality/rights.
For example, the “ADD ADDRESS” action is locked in as PASSTHROUGH=YES, to put it in RoS speak, and what you call STOP TRAVERSAL (passthrough=no) for these actions DOES NOT APPLY.
Some actions ----> match and passthrough = no (stop traversal)
Some actions ----> match and passthrough = yes
Overall these actions and functionality are applicable to all Chains and all IP FIREWALL Entities.
Mangling is a funny case as it is the one type of IP FIREWALL rule that has passthrough as both an ACTION and an option.
Since its used for primarily marking packets (only for the router to use), one has to be able to mark things and then ensure the rule is passed to the next rule or NOT,
and thus passthrough is defaulted to YES.
So the extra option is included and primarily to tell the router when to use STOP TRAVERSAL (dont try to match any further rules).
Thus the last rule, I think I can safely conclude for an associated set of mangle rules must contain an ACTION that provides the passthrough option separately, besides the obvious action of Passthrough
(change MSS/TTL, clear DF, mark packet/connection/routing, set priority, route, strip ipv4 options)
“Stop Taversal” for all chains can be tied to ACTIONS: accept, drop, reject, return, tarpit, the rest can be assumed to be passthrough=yes (in effect).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Concur, the conclusion is that if it works for RDP, there is no difference in the config for FTP and thus,
its an issue with the FTP server or the PC it resides on or the port number and the ISP have some conflict 2121 ??
Hence my previous post! (although it was based on ignorance of action results or how they may affect the efficacy of rules).
You can see non-zero counters in screenshot in first post, so it doesn’t look like ISP has anything against 2121.
Then its software firewall on PC where FTP resides or the FTP program itself blocking something.
Thanks for the elaborate answers:), but … as I wrote in my previous post: the backend machine does listen on port 21 as I can telnet to it from the internal network , the same network the MikroTik resides on. The same machine to which the RDP forwarding works.
Then check what happens with incoming packets, you can use Tools->Torch on LAN interface and look for packets to 192.168.55.5:21, or to make sure you don’t miss any, use logging rule to catch them:
/ip firewall mangle
add chain=postrouting dst-address=192.168.55.5 protocol=tcp dst-port=21 action=log
If it logs something, then it’s correctly passing through router. Next step may be packet sniffer on server, and if you see them there, then it’s definitely not router doing something wrong.
Turns out that I needed to restart the ftp service on the Windows machine. This doesn’t make any sense to me as I was able to telnet to port 21 from the internal network. It just didn’t accept connections from the MikroTik, which resides on the same internal network. I’m totally baffled.
Thank you all for your time and involvement.
Yup, nothing to do with MT…
Best remedy in IT is turn it off and then on LOL, especially windows…