Specific question on Port forwarding

I am setting up a basic router.

I had added the following under ip firewall nat:

0   chain=srcnat action=masquerade src-address=192.168.1.0/24 
     out-interface=WAN 

 1   chain=dstnat action=dst-nat to-addresses=192.168.1.10 protocol=tcp 
     in-interface=WAN dst-port=3389 

 2   chain=dstnat action=dst-nat to-addresses=192.168.1.1 to-ports=8291 
     protocol=tcp in-interface=WAN dst-port=8291

Here are the Filter rules:

0   ;;; Allow esatblished connections
     chain=input action=accept connection-state=established 

 1   ;;; Allow related connections
     chain=input action=accept connection-state=related 

 2   ;;; Drop invalid connections
     chain=input action=drop connection-state=invalid 

 3   ;;; Allow UDP
     chain=input action=accept protocol=udp 

 4   ;;; Allow ICMP
     chain=input action=accept protocol=icmp 

 5   ;;; Allow connection to router from local network
     chain=input action=accept in-interface=!WAN 

 6   ;;; Drop everything else
     chain=input action=drop 

 7   chain=forward action=jump jump-target=customer in-interface=WAN 

 8   ;;; Drop invalid connection packets
     chain=customer action=drop connection-state=invalid 

 9   ;;; Allow established connections
     chain=customer action=accept connection-state=established 

10   ;;; Allow related connections
     chain=customer action=accept connection-state=related 

11   ;;; Log dropped connections
     chain=customer action=log log-prefix="customer_drop" 

12   ;;; Drop and log everything else
     chain=customer action=drop

Is there something i’ve setup incorrectly in the filter rules that is not allowing the nat rules to function?

common mistake is to put your dst-nat rules after the masquerade.
Make your masquerade rule last on the list.

You have to allow forwarding of ingress packets to those local address in your firewall.

/ip firewall filter
add action=accept chain=forward comment="" disabled=no dst-address=192.168.1.10 dst-port=3389 in-interface=wan protocol=tcp
add action=accept chain=forward comment="" disabled=no dst-address=192.168.1.1 dst-port=8291 in-interface=wan protocol=tcp

Place these two rule above the drop everything rule.

You have to allow forwarding of ingress packets to those local address in your firewall.

iirc, I don’t think it’s necessary to have the filter rules as dst-nat is processed prior to filter in packet flow.
The dst-nat rules themselves allow the forwarding of the packets.
Am I wrong??
Wouldn’t be the first time. :open_mouth:

I have done this and still cannot connect. I can see in Winbox packets hitting this rule, but no connection. I will try the second idea in conjunction with the first tomorrow.

Should I be doing this a different way, like EoIP?

I mainly want to be able to manage my network from anywhere, but still have it secure from DOS/Brute Force, etc. The two ways I have been doing this with linsys type boxes is allowing remote management of the router and opening up port 3389 for RDP connections to my servers. I have been reading the manuals about EoIP, but it seems too limiting for the traveler. I have looked into VPN but the client side doesn’t seem very straight forward and I have not seen a good free client that will work with win xp, unless there is some built in solution I am unaware of.

Try something like…
place before masquerade

/ip firewall nat
add action=dst-nat chain=dstnat comment="" disabled=no dst-address=<your public ip> dst-port=3389 in-interface=WAN protocol=tcp to-addresses=\
    192.168.1.10 to-ports=3389

You will be right if he doesn’t have a filter rule that drop everything not explicitly allowed. The #7 filter rule force a jump to customer chain if the in-interface is wan and rule #12 then drop the packet if does not match any prior rule. This is where his packets get dropped even after been processed and forwarded by dst-nat. Consequently, he must allow those packets in filter as described in my earlier post.

You’re wrong :wink: It’s not important which is first: dst-nat or masquerade. Masquerade can be only put in src-nat chain. So you are talking about two different chains which are processed separately.

I did as you suggested.

It is working, here is my current rule chain:

 0   ;;; Allow esatblished connections
     chain=input action=accept connection-state=established 

 1   ;;; Allow related connections
     chain=input action=accept connection-state=related 

 2   ;;; Allow UDP
     chain=input action=accept protocol=udp 

 3   ;;; Allow ICMP
     chain=input action=accept protocol=icmp 

 4   ;;; Allow connection to router from local network
     chain=input action=accept in-interface=!WAN 

 5   chain=forward action=accept protocol=tcp dst-address=192.168.1.10 
     in-interface=WAN dst-port=3389 

 6   chain=forward action=accept protocol=tcp dst-address=192.168.1.1 
     in-interface=WAN dst-port=8291 

 7   ;;; Drop invalid connections
     chain=input action=drop connection-state=invalid 

 8   ;;; Drop everything else
     chain=input action=drop 

 9   chain=forward action=jump jump-target=customer in-interface=WAN 

10   ;;; Drop invalid connection packets
     chain=customer action=drop connection-state=invalid 

11   ;;; Allow established connections
     chain=customer action=accept connection-state=established 

12   ;;; Allow related connections
     chain=customer action=accept connection-state=related 

13   ;;; Log dropped connections
     chain=customer action=log log-prefix="customer_drop" 

14   ;;; Drop and log everything else
     chain=customer action=drop

Is this setup in the correct order and are their any redundant chains that don’t need to be there?

Your rules are in order.

I can reach port 3389. The other port, which is the winbox port, is not reachable from winbox. Is there some internal routing that needs to take place to allow the winbox port to go through or to the WAN interface?

To connect to that router, you need to be playing with the INPUT chain and not the FORWARD chain.

So if you have a drop-all rule on the INPUT chain then you need explicitly allow this with a rule for port 8291.

Make sense?

This is the filter list in the Mikrotik. What about the nat list, does anything have to happen ther? I have two External ISP connecitons and wnat to forward them to various systems inside. Can I do it with the filter rules alone?

Any ‘port forwarding’ of sorts needs to happen under the NAT section of the firewall.

I have a rule to the port forwarding from my input interface with a destination port of 81 to an local address of 192.168.1.104, port 80. Packets are showing as going through the rule, but none of them are getting to the server (192.168.1.104) – nothing in server logs. Is there something else I must do to enable the natted packets to the local address?

Post the exact rule.

Here is the rule:

4 ;;; www:81
chain=dstnat action=dst-nat to-addresses=192.168.1.201 to-ports=81 protocol=tcp
in-interface=pppoe-out1 dst-port=81

This looks correct. If I were to browse

http://yourdomain:81

I would connect to your internal website.

Just make sure that the default gateway on the webserver is the same as the Mikrotik router.

It worked! Thank you.

I have another ISP/Interface on the MT. How can I do the same thing with packets coming into the other address? It works coming in the pppoe-out1 interface, but I would like to use another interface and do the same type of thing.

The router has an inside address of 192.168.1.254 and the webserver uses that as it’s default gateway.

What do I need to do to come in the other interface and do the same thing?

Just change the ‘in-interface’ part of the rule