Firewall killing NAT rule

RouterOS General
1

Let me start by introducing myself.

My name is Karl, and I am from South Africa. I am a seasoned Mikrotik installer/programmer/whatever I can get it to do guy. I have been referring back to these forums often for help when I start scratching my head, so thanks to all of you for the bits of info that point me in the right direction when I hit my head on a wall.

I have created a Firewall Filter that blocks incoming ports 1-1024, however I have added a backdoor rule in the NAT section to use port xxxx to point to Port 80 on 192.168.x.x on Ether2.

My NAT rule works fine, until I enable any the Firewall Filter rule. Then it dies. I still have access to Port 80 on 192.168.1.1 from any of my four subnets on Eth2-5.

Here are my rules…

NAT:
/ip firewall nat
add chain=dst-nat protocol=tcp dst-port=xxxx in-interface=PPPoE action=dst-nat to-address=192.168.1.1 to-port=80

This rule works fine to port forward xxxx to 192.168.1.1:80 on Eth2

FILTER:
/ip firewall filter
add chain=input protocol=tcp dst-port=1-1024 in-interface=PPPoE action=reject

This rule is blocking all incoming connections on ports 1-1024.

Together, the NAT rule fails.

Any ideas?

2

Filter comes after dst-nat. 192.168.1.1, which is the destination address of the packet after the dst-nat has been done, is one of local addresses of your Mikrotik, so chain=input of /ip firewall filter is used. The dst-nat rule only redirects the packet (changes its destination address and/or port), but that alone doesn’t mean that it would bypass the filter. So one possibility is to add connection-state=!dstnat to your action=reject rule in /ip firewall filter.

Unless you’ve hidden some additional conditions (like src-address or src-address-list) in the dst-nat rule to simplify the description of the scenario, the configuration is highly unsafe as internet is full of robots which scan for any open port anywhere and try to connect using all sorts of L7 protocols (telnet, http, ssh, …). So exposing management access to your Tik through plaintext http to the whole internet, even though on an unusual port, is a Bad Idea.

3

If indeed the filter forward rule is applied after NAT, then port redirection wont work (higher port to lower port) and thus one should just put the allow dstnat rule before the kill all ports rule in the forward chain order and it should work.

4

@anav, have you ever bothered to look at the diagrams I’ve linked above?

5

Thanks sindy, that makes perfect sense. However, we ended up implementing an even more drastic measure now.

In order to connect to your main RB, which since has been upgraded to a RB2011, or any of our client’s RBs, we have to tunnel into our network using L2TP, giving you a local IP address. Since our office has a static IP this means we have been able to set rules on our the RBs on the field that we manage, such that it only allows you to log in via our Public IP or the respective RB’s local IPs.

We had a recent event where one of our main servers got hacked. So we ramped up security everywhere.

6

also worked out that an easier way to do this, was just to change the service port to {insert port number here} and it does the same thing, just with less steps.
(/ip service)