Pretty straightforward. My server logs, though, are show connections from 192.168.1.1 (router’s LAN IP). This is a problem because malicious and non-malicious login attempts look the same to the server. I’ve had to whitelist 192.168.1.1 in order to keep the server from automatically blocking everything.
The question is: what is the magic that makes RouterOS NOT* change the src IP to itself? Before we bought a Mikrotik, we used IPtables:
-A PREROUTING -d 1.2.3.4/32 -i eth0 -j DNAT --to-destination 192.168.1.200
-A POSTROUTING -s 192.168.1.200/32 -o eth0 -j SNAT --to-source 1.2.3.4
Hi blake, your explanation is hard to follow.
One has no idea what functionality you would like to have (user requirements not config).
No diagram of network…
Best start would be to post your config
/export hide-sensitive file=anynameyouwish
Apologies. Below are some excerpts from the exported file. I’m currently troubleshooting 192.168.1.41. Trying to make the external IP address stay intact for the internal server.
We do have a standard NAT for the “rest” of our internal IP addresses. Outside of those specifically mapped to internal IP’s. In essence, I still need to do traditional NATing for the rest of the network. It seems to me that we still need a rule to deal with the rest of us?
Hey! That worked. I’ll be darned. It didn’t have anything to do with the src-nat,dst-nat rules. Thank you! And now to figure out why my FTP server doesn’t work… PORT command breaks when communicating through the mikrotik. I think part of the issue was* the remote IP address showing as the LAN IP of the router but now that that is solved, I’m still getting “500 Illegal PORT command.”
I can connect to the FTP server from another LAN machine with no problem. Both PASV and non-PASV modes. Friggin FTP. I wish I didn’t have to have this service in play.
Not enough info. Ilegal PORT command is most likely private address in it. No sane client should be using active mode (PORT) in the first place. Routers (in this case it would be client’s router) usually transparently deal with it, but it requires plaintext unencrypted FTP on standard port 21. It’s much better to use passive mode (PASV), then correct configuration depends on server operator who should be much better at configuring such things than regular client.
Also if you try to use this rule, it’s completely wrong:
That broken rule was grasping at straws for the first issue in this thread. The FTP client in question was likely coded around 1998. I don’t think it’s using PASV mode. Though, you do give me an idea. I am pretty sure that this client is hosted at AWS. And I know that AWS puts private IP address onto their EC2 instances with some networking magic to “link” that VM to an external public IP. I wonder if that is playing havoc on it’s ability to make FTP connections through my MikroTik router? I’ll contact the vendor.
Active mode (with PORT command) means that client tells server to what address and port it should connect for data connection. The thing in its original form is completely incompatible with NAT, because client knows only about own local address and sends that to server. And of course server can’t connect to it.
For active mode to work behind dumb NAT, you’d need NAT-aware client that would get its external public address and send it to server, and additionally it would need to have ports forwarded to itself. In most cases it’s very unlikely config. So what happens is that routers often inspect traffic on port 21 and if they find FTP commands, they automatically rewrite addresses and dynamically forward ports to client. It works as long as there’s no encryption on control connection (but you probably don’t need to worry about that with 1998 client). Bigger problem is that not all routers have to do this.
The right solution, if you need to stick with FTP, is to use passive mode. I don’t know what’s so special about your client, but if it doesn’t support it, it should be possible to find some replacement.
Yep! That’s the way I understand it as well. Classic FTP traffic:
SYN->ACK->SYNACK handshake:
client:randomport → server:21
server:21 → client:randomport
Then later:
client:randomport {PORT command, I would like you to connect back to me on port XXXX from port YYYY} → server:21
server:YYYY → client:XXXX
That’s the breakage. The second conversation for commands like LS. What a world the internet used to be. (I’m almost 40 years old). I’m asking the vendor to see if they can get their FTP client to talk in PASV mode.
I very much appreciate the time you’ve spent with me on this post. We’ve initiated with the slow-responding monster that is the vendor. We shall see what shakes out on the other side.
