Hello,
I am very new to the OS, but follow instructions well. I followed several samples on the wiki detailing how to forward requests on a certain port, to a specific internal IP. These dstnat rules are not working for me for some reason. Once I have created them, I can see the counters incrementing in winbox for the rule…however I am still unable to connect to the resource. Below is a print paste of the two rules I cant get to work:
Yes I do. The only other rules I have presently are a port 80 redirect on the internal (private) interface to the web cache. And a masquerade srcnat for NAT.
Is the masquerade causing a problem (breaking the connection as the host is not receiving info back from the expected IP?) I suppose that would make sense to me logically, but i dont know how to get around it.
Thanks ,
Jeremy
Hi again,
There are no routing entries outside of default. There are currently only 3 entries in routes, all default. I have not done anything further than run setup, enable dhcp,transparent web proxy, local dns. Another clue, I attempted to redirect a user using a dst nat rule from their source IP, dstnat port 80 to the address of my internal webserver, and that to appeared not to work. Let me know if I could paste anything else that would be helpful. A side note, I really appreciate your being helpful on this issue…user forums and helpful souls such as yourself are ideal.
Jeremy
Thank you for the input psip. I went ahead and made the change to remove in-interface, and still have the same problem. I believe that is something I did going back and forth trying to get this working. Without that parameter specified, both rules for ssh and rdp still fail to work, even though you can see the packet counter for the rule incrementing. On another note, ethereal does see packets arriving when attempting to rdp to the device. It almost seems as though the traffic is only flowing in, and not allowing any return communication? Either way, im stumped.
So you can definately connect to these ports OK from inside the network, and you can definately ping your public addresses from outside ?
Maybe temporarily allow port 22 in the input chain and test to make sure you can SSH to the router itself, work through it piece by piece.
You rules look OK to me and should work, even the one with the in-interface should work, but you don’t need that set.
Hello Paul,
Yes, I can connect to both with no error from inside the network. I also confirmed that both had the correct subnet and gateway, and could communicate with the MT with no issue. At your recommendation I also created an input chain for port 22, and see the same behavior (connection timed out) when attempting to connect to the external IP. I have pasted all firewall>filter rules below. I really appreciate all of your help, please let me know if I can give you any more information.
Jeremy
[admin@MikroTik] ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward in-interface=public action=jump jump-target=customer
1 ;;; Drop invalid connection packets
chain=customer connection-state=invalid action=drop
2 ;;; Allow established connections
chain=customer connection-state=established action=accept
3 ;;; Allow related connections
chain=customer connection-state=related action=accept
Rule 6, you need to change to dst-port, then try to connect again, making sure of course that you disable the relevant forward rule for port 22.
What I was trying to get you to do is connect to the port 22 (SSH) on the mikrotik itself just to ensure that you can get port 22 into the router. Also, I’m not sure if you have port 22 enabled on the router if it will cause any problems with forwarding it, it shouldn’t, but it may pay to disable that service in IP->Services just in case.
In order to use dst-nat, your dst-nat destination address (to-address=) needs to be on the same IP Network as the Interface where the data leaves.
If you dst-nat to-address=172.21.2.2, then the Internal Interface on the Mikrotik need to be on the same IP Network. It needs the MAC Address in order for dst-nat to function, and if you are dst natting to a routed IP address, the router will not know the MAC address of the destination IP.
Hi Jeremy,
as you declared “rule 6” to allow port 22 in firewall filter for SSH connections - did you aslo define port 3389 there to allow incoming RDP connections
I only came across this thread and I found 2 things.
1\ I do not agree that address where the communication is dst-nated has to be from the same subnet as the address of the interface through which it is leaving. However, the dst-address has to exist (naturally) and you have got to have a route to it, if you want it to work.
2\ In my opinion you do not need to allow port 22 as extra action since there is no rule to deny it. Moreover communication to ssh is normally where dst-port is 22, not the source one, source ports are allocated dynamically.
Although I came across it very quickly I have not found why it should not work. Try to use torch/ethereal and other tools to state whether packets are redirected correctly and not processed because of other reasons, for example.
I have a similar issue and wanted to know if anyone has a fix or know how to resolve:
Port forwarding works but only if you are on the outside of the private network. For example I can sit outside and get to all my email and webservers no porblem.
Once inside tring to pull up any service pointing to the outside IP it dies at the MT box?
There are no firewall rules except for dst-nat at this time. Curious to know that I can stick a cheap linksys in and everthing works just fine from both sides.
[admin@MikroTik] ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward in-interface=public action=jump jump-target=customer
1 ;;; Drop invalid connection packets
chain=customer connection-state=invalid action=drop
2 ;;; Allow established connections
chain=customer connection-state=established action=accept
3 ;;; Allow related connections
chain=customer connection-state=related action=accept
Filter Rule #6 - should be deleted. Besides you have this rule after all of your other rules so it is dropped and logged before it even gets to it…
NAT Rule #3 - “src-address-list=”" dst-address-list=“” " are you using src and dst addresses here? If not then get rid of these parameters…they’ll just cause problems otherwise.
In the above set of rules I do not see an allocation for a ‘new’ connection. You have related, established, and invalid - where is new?
You are ONLY filtering requests coming from the outside - “in-interface=public”, was this your intention?
I also don’t know how you ‘allow’ connections to your servers, one of the security features I use among others is IP addresses…if you use this feature then you will also have to match the masqureaded IP from the MT and add it to your list of ‘allowed’ IP addresses for your servers…because you have ALL requests for external IP addresses masqueraded "0 chain=srcnat out-interface=public action=masquerade ". When connecting using an inside IP address you’ll have to do the same on the server - the MT isn’t involved - it’s a direct connection from client to server but the IP address of your client will need to be in the ‘allow’ list on the server…
