The connection works over a pppoe WAN with public ip address released to pppoe interface
The non-working connection is a natted ISP router (routerboard interface is on the LAN side of all_ports_natted ISP router)
While trying an ftp connection to failing WAN , I have a timeout error.
Checking manually the connection from a linux cli, on the failing WAN I can access the FTP server, but when I try to issue a transfer or a ls command I get something like :
227 Entering Passive Mode (10,0,10,254,220,167).
and after 20 seconds:
ftp: connect: Connection timed out
I suspect it has something to do with port 2121 to 21 forwarding together with natted connection…
It’s something that needs to be done on natted ISP router. It most likely watches only port 21 for ftp control connections, same way as RouterOS does by default. If server’s adress is 192.168.1.100 and in reply to PASV command it was changed to 10.0.10.254 (it should be the WAN address), it means that conntrack’s ftp helper works with port after dstnat. Same thing should happen on ISP’s router too. So if there’s no option to add port 2121 as watched on ISP router, you could move the transition from port 2121 to 21 there and it should help (instead of :2121 → :2121 → :21 do :2121 → :21 → :21).
If all_ports_natted means that whatever comes to the ISP’s router public-facing IP address:port X is forwarded to a configured private side address:port X, and you’ve configured that private side address to be the one of your Mikrotik, I’d assume that the reason why FTP to that public address doesn’t work at all is that you don’t use connection-marks to note down which WAN to use to route out the responses. See this topic for the details (check the last paragraph of that post first).
But there may still be an issue even if/after you have configured this properly, as FTP uses one TCP session for control communication and creates other TCP sessions for data transport. The parameters of the data transport session are communicated using the control session, and the firewall must replace the private side IP and port in the control message by its public side IP and port. The firewall needs to be told which TCP port is used for the control communication so that it would treat the control connection that way (it doesn’t check each and every TCP session to be a FTP control one), so if this is not configurable on the ISP’s modem, you cannot expect it to recognize an FTP connection on port 2121.
Correct routing of replies must already be there when control connection works. It’s the addresses for data connections, 10.0.10.254 is clearly not public.
I always say that that FTP and NAT is not the best combination, but FTP and dual-WAN NAT is yet another level. It’s doable with unsecure plaintext FTP, but if there would be requirement for encryption, it would make it impossible (for passive mode).
It depends. If done right, there’s no difference in security. FTP’s problem is more difficult configuration, but it’s nothing extreme either. Historically, FTP was much more common in Windows world, so a lot of people are used to it (although it doesn’t apply as much to encrypted variant). It’s true that the multi-connection mode of operation is not very practical, transfering thousand small files means thousand new connections, it’s not exactly efficient (there’s another mode that could do it with one data connection, but almost nothing supports it, both servers and clients). But still a lot of people like FTP…
Well, my statement was more oriented to handling by NAT/firewall, where the single TCP session for both control and data transfer makes the difference between boredom and headache I didn’t even know there was a native FTPS client on Windows, which would be the only reason I could imagine to prefer FTPS there over SFTP (which requires installation of a 3rd party application).
Actually, I’m not sure about native Windows FTPS client, I’d say probably no, unless they added something recently. And thinking of it, it may be really just my skewed view, a lot of people around me used FTP a lot, own FTP servers were popular, there were many different FTP clients (and everyone chose their favourite one), when one had own website, hostings provided FTP access almost exclusively, etc. But it’s true that it could be just my bubble.
Thank you for replies,
So the issue is the double nat, and it doesn’t happen in pppoe as the public IP is directly assigned to MT WAN interface
Yes , all ports from public ip address are natted from router (10.0.10.1) to routerboard WAN (10.0.10.254)
Connection mark for dual wan already done this way:
My problem : there is already another FTP server running on public ip port 21 (and in fact it still works despite the double nat path) that’s why I need another port to be redirected to LAN port 21 of the second ftp server.
If the other (ISP) router had RouterOS too (I guess it probably doesn’t), the solution would be:
/ip firewall service-port set ftp ports=21,2121
Try to find, if it has something like this. But I don’t remember seeing this in any simpler router.
Other theoretical option is to not rely on conntrack helper at all and do all configuration on server. It means forwarding not only one port for control connection, but also port range for data connections to server. Server must be aware of it and the used public address, and then it can construct correct replies for PASV command. It’s the same what’s required for encrypted FTP. Trouble is that it’s nearly impossible in practice, because internal server won’t be able to tell from which WAN the connection came, so it can’t choose the right address.
If you had some really configurable FTP server which would be able to listen on two different ports, each with different external config, it could be done this way, you’d simply forward 2121 from each WAN to different port on server. Trouble is, I have no idea if such server exists. Or you could perhaps run two server instances with different network config, but otherwise same (users and everything). It would work, but it would be extra work.
Another desperate thing to try (but it probably won’t work) is to setup described config, hardcode it for WAN2 and hope that conntrack will override the address for WAN1. But since it would be valid public address, I assume it won’t. But I didn’t try it.
Edit: Stratch the last paragraph, if it would do something, it would interfere even with WAN2 connections.
