Hi Folks,

im a newcomer to mikrotik but am familiar with networking in general, I have an issue that research hasnt solved yet.

we have 5 mikrotik routers setup with rip. networks are..

172.21.0.0/24
172.21.1.0/24
172.21.2.0/26
172.21.2.64/26
172.21.2.128/26
... and so on.. etc

one of the routers is setup as the gateway, very basic firewall settings, srcnat masq for nat.

xxx.xxx.198.224/27 from our ISP.
xxx.xxx.198.226 on the wan side
172.21.0.1/24 on the lan side

the above setup works great... rip works fine, everyone can get on the internet etc.


the problem............

i try to port forward xxx.xxx.198.226 to 172.21.2.67 using port 5900.

command is.. (right off the wiki)

/ip firewall nat add chain=dstnat dst-address=xxx.xxx.198.226 protocol=tcp dst-port=5900 \
action=dst-nat to-addresses=172.21.2.67 to-ports=5900

i am not able to reach the internal machine from the outside. looking at the byte count for that rule, it does increment, but only a little. I have tried a number of variations without success. any ideas? are there issues port forwarding to other networks on the inside?

pings and traceroutes all seem normal.
the machine is reachable on the inside from any of the other networks.

any ideas would be great!

tia

check your firewall filter rules. sniff on the 172.21.2.67 whether if actually receives and sends packets over that forwarded connection. use firewall rule with action=log to see more info about in and out interfaces for those packets...

I have exactly the same problem:

/ip firewall nat
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=\
172.25.53.207 dst-port=8080 protocol=tcp to-addresses=192.162.50.254 \
to-ports=8080
add action=src-nat chain=srcnat comment="" disabled=no protocol=tcp \
src-address=192.168.50.254 src-port=8080 to-addresses=172.25.53.207 \
to-ports=8080
add action=masquerade chain=srcnat comment="" disabled=no src-address=\
192.168.50.0/24

IP of the router's public interface is 172.25.53.207

The counter on the first dst-nat shows the connection coming in. Second rule stays 0 and although the last, masq. rule counts up due other traffic it never counts up when no other traffic around and only the port forward should pass. (But that should be ´catched´ the rule no.2.

If I sniff on the public interface (wlan1) I see this, amongst other (winbox) traffic:

21 1.091 wlan1 192.168.5.3:4016 172.25.53.207:8080 (http-alt) tcp 62
22 1.091 wlan1 192.168.5.3:4016 192.162.50.254:8080 (http-alt) tcp 62

If I sniff on the private (eth1) interface nothing happens.

Same with torch, wlan1 interface shows the bytes, eth1 stays idle.

All my firewall rules are disabled for this test. I have full winbox and http acces to that router. I double checked the remote host I want to reach (a domestic Netgear Wifi router I want to manage from its WAN port. This port is opened for ALL and has address:port 192.168.50.254:8080

I tried to change the order of NAT rules, I tried with disabled masq rule for the LAN, I tried other port settings.
It just looks like traffic is get lost in the router. This is a text book setup, why the hell is it not working!

And this is what the logs shows:

03:54:33 firewall,info portforward forward: [flash=]in:wlan1 out:wlan1[/flash], src-mac 00:0c:42:61:ee:cf, proto TCP (SYN), 192.168.5.3:4212->192.162.50.254:8080, len 28
03:54:33 firewall,info portforward forward: in:wlan1 out:wlan1, src-mac 00:0c:42:61:ee:cf, proto TCP (SYN), 192.168.5.3:4212->192.162.50.254:8080, len 28

Yet again, it looks like traffic is just bounced back: "in:wlan1 out:wlan1"?????



(By the way, what does this "len xx" mean. I never understood this in the logs.)

If the IP of what you're trying to manage is 192.168.50.254, why are you port forwarding to 192.162.50.254 (second octet is different)? Since that's a public IP address and probably not matched by any specific or connected routes, is it just going back out the wifi1 because that's where the default route points to?

Edit: len is the packet size, a SYN packet isn't very big at all.

towerbridgetech, if what Chupaka suggested doesn't get you to a solution, at least post your actual routes, and firewall and NAT configuration. What you're trying to do definitely would work.

If the IP of what you're trying to manage is 192.168.50.254, why are you port forwarding to 192.162.50.254 (second octet is different)? Since that's a public IP address and probably not matched by any specific or connected routes, is it just going back out the wifi1 because that's where the default route points to?

Ok, I have to bow my head deep in shame..... You are completely right.

I think that's what you get with too many hours deep into the night watching these monitors..... ..... I think I need some fresh air....

It works now, thanks anyway!ª

mine was fixed when i realized my firewall rules were incorrect. forwarding works awesome.

thanks

I have a similar setup but my public ip is dynamic so i cannot specify any ip for dst-address. Can i specify the getaway interface receiving the dynamic ip instead? How do I do it?

/ip firewall nat add chain=dstnat dst-address=10.5.8.200 action=dst-nat \
to-addresses=192.168.0.109

use "in-interface=Public dst-address-type=local". it will match all traffic to the router address from the outside

Thanks, its working like a charm but now i cant access mikrotik router via the public ip. Only from inside the lan. what do i add?

Exclude the ports that you need to be terminated on the router. Something like dst-port=!22 to exclude SSH from being NAT'd.

I exclude it from the dst-nat rule that forwards connection to internal server?

Yes. Something like the below:
To forward all TCP traffic except SSH to that server. The downside is that if you also need to forward UDP, ICMP etc. you'll have to add at least one more line (without "protocol=tcp dst-port=!22") later in the chain as that now only matches TCP traffic. So forwarding everything (all protocols) other than SSH would look like this:
Alternatively, you can exempt the excluded port from being NAT'd higher up, and just accept it first so that it hits the router:

Thanks again.It works.