Hello
I’m new to MikroTik/RouterBOARD, but I’m not new to networking. So, maybe it’s just me who don’t really understand the RouterOS (6.40.4) on my hAP ac. I have set up a couple of dstnat for SSH and HTTP, works fine. I have my own SSH and HTTP server on a DMZ VLAN behind the MikroTik, which btw have got it’s outside external IP via DHCP from my ISP.
Well, because I already had two dstnat running fine, I was surprised to find out my FTP (port 21) dstnat didn’t. I know the FTP NAT can be ‘interesting’ depending on how it’s allowed to work, active or passive. My first test was to switch off and on all different FTP support on my MikroTik (it’s internal FTP server and the ‘inspection’ service). It did not work in either way. Down to some Wireshark and find out that my external FTP client does get a TCP reset immediately after it sent the SYN. Looking at tcpdump on the FTP server side did show that the SYN arrived and that the server answer with a SYN,ACK back. After adding almost 2-second delay to my FTP server (via VMware advanced network setting), I could tell that the RST from MikroTik was sent directly after it recieved the SYN, not waiting for the SYN,ACK from the FTP server. Yes, the SYN,ACK will ‘hit’ the ‘invalid’ forwarding filter due to lack of entry in the ‘NAT session state table’.
If I do the same using my working dstnat tcp port 80, I also see the SYN pass. But instead of having the SYN,ACK being dropped by the invalid filter rule as in the FTP case, I can see that the http SYN,ACK response ends up in the forwarding chain filter for established, related, untracked rule (as it should).
So, I’m out of ideas how to set this thing up for my FTP. BTW, I also test to use a different tcp port (to bypass any ‘inspection’ intelligence in the Tik), but with no luck. I also have tested it with another FTP client, no luck. I have no problem to connect to the FTP DMZ server from my ‘inside’ network. I don’t dstnat from inside to DMZ, I only route traffic from inside to DMZ passing some allow/deny filters. I also tested netmap action instead of dst-nat, no luck. Have I forgot to switch some ‘special’ FTP feature off in the Tik-settings or are there predefined ‘intelligence’ handle FTP. But this is down to a single SYN, I have not even reached the FTP negotiation yet, hmm. Is there some way to have internal process debugging switch on to see why the Tik decide to respond with a reset to my SYN?
Anyone have any idea what I should do, test or change . . . please? For the moment, my only option I know works is going back to my old Cisco ASA, but I really don’t like that option. I want to solve this with my Tik.
Regards
- Per Håkansson
Some outputs:
FW FILTER
chain=forward action=accept connection-state=established,related,untracked log=no log-prefix=“-e-r-u-”
chain=forward action=drop connection-state=invalid log=yes log-prefix=“—x—”
FW NAT
chain=dstnat action=dst-nat to-addresses=10.100.100.114 to-ports=80 protocol=tcp in-interface-list=WAN dst-port=80 log=yes log-prefix=“”
chain=dstnat action=dst-nat to-addresses=10.100.100.3 to-ports=21 protocol=tcp in-interface-list=WAN dst-port=21 log=yes log-prefix=“-------”
FW SERVICE-PORT
ftp 21 ← Have tried this ON or OFF, also moved it to port 2121, no luck
IP SERVICES
FTP 21 ← Tried on and off, also on port 2121, no luck
OUTPUT FROM REMOTE SYSLOG WHEN I DO A CONNECTION
FTP - Dont work, are never accepted by the Tik and therefore never added to ‘established session’-table. The reset are immediately sent by the Tik, even before the FTP server SYN,ACK arrive
firewall,info ------- dstnat: in:outside1-intf-R out:(none), src-mac 00:08:ae:8e:77:e0, proto TCP (SYN), SSS.SSS.SSS.SSS:6135->NNN.NNN.NNN.NNN:21, len 60
firewall,info —x— forward: in:dmz-bridge(dmz-vlan) out:outside1-intf-R, src-mac a8:20:66:1d:e4:93, proto TCP (SYN,ACK), 10.100.100.3:21->SSS.SSS.SSS.SSS:6135, len 60
HTTP - Works
firewall,info dstnat: in:outside1-intf-R out:(none), src-mac 00:08:ae:8e:77:e0, proto TCP (SYN), SSS.SSS.SSS.SSS:17057->NNN.NNN.NNN.NNN:80, len 60
firewall,info -e-r-u- forward: in:dmz-bridge(dmz-vlan) out:outside1-intf-R, src-mac a8:20:66:1d:e4:93, proto TCP (SYN,ACK), 10.100.100.114:80->SSS.SSS.SSS.SSS:17057, NAT (10.100.100.114:80->NNN.NNN.NNN.NNN:80)->SSS.SSS.SSS.SSS:17057, len 60
OUTPUT FROM TCPDUMP AT FTP SERVER
21:30:29.909586 IP SSS.SSS.SSS.SSS.6084 > 10.100.100.3.21: Flags [ S ], seq 1750062707, win 65535, options [mss 1410,nop,wscale 6,sackOK,TS val 787634772 ecr 0], length 0
21:30:29.909681 IP 10.100.100.3.21 > SSS.SSS.SSS.SSS.6084: Flags [ S. ], seq 2331533236, ack 1750062708, win 28960, options [mss 1460,sackOK,TS val 1492845502 ecr 787634772,nop,wscale 7], length 0