Filter rule is accepted, but dst-nat not working

Hi,

I have an NAT issue with mikrotik CCR1016-12G - namely I can’t see any packets going to my dst-nat rules and dst-nat rules are not working.

I have tried disabling filtering rules that might drop any packets, and I’ve also tried to make a specific rule to accept a specific port with no luck:

1 chain=input action=accept connection-state=new protocol=tcp src-address=0.0.0.0/0 in-interface=ether01-gateway dst-port=8088

I can see the packets coming in to the filter rules and assume that they get accepted(as I have the previous rule in place), but no packets are going to the dst-nat part:

1 chain=dstnat action=dst-nat to-addresses=192.168.1.88 to-ports=80 protocol=tcp src-address=0.0.0.0 dst-address=“Outer-IP” dst port=8088

In addition, I’ve also copied the same configuration to my other mikrotik routers and it worked.

What could be the issue that I don’t see any packets going to NAT - could it be a physical problem with the device?

Thanks in advance.

You got it wrong, first there’s dstnat and then filter.

But the obvious mistake in this case is src-address=0.0.0.0, which means exact source address 0.0.0.0 and that’s not going to happen. You can either change it to 0.0.0.0/0 to mean any address or completely remove this option.

Two things.

  1. If you want to make a rule apply regardless of src-address, then there’s no need to specify src-address=0.0.0.0/0 (you did this in your input filter rule as well)
    Not specifying a src address is exactly the same, and doesn’t require the system to actually check the IP address at all. In other words, it wastes CPU resources to specify src-address=0.0.0.0/0

  2. If your dstnat rule actually has “src-address=0.0.0.0” (without the /0 at the end) then that’s your problem. If you leave off the /0, then this implies 0.0.0.0/32, which means that the src-address must be specifically 0.0.0.0 - which isn’t even a valid IP address in the first place.

Also, unless you’re trying to support hairpin NAT (hitting the public IP pinhole from the LAN side of the router), there’s no need to specify dst-address=x.x.x.x - especially if your WAN address is dynamic. If it’s dynamic, then every time your IP address changes, you’ll need to go into the router to change this rule.

I prefer to use “in-interface=wanInterfaceNameHere” instead of dst-address=x.x.x.x
If you need to support hairpin NAT, then instead of in-interface, use dst-address-type=local and also dst-address=!192.168.0.0/16

I for one prefer dst-address=x.x.x.x (for static addresses), because it does exactly what I want, nothing less and nothing more. For example, if I happen to get another public address, which I want to use with different port forwarding, original dstnat rule is still valid and I don’t need to touch it (unlike if I had in-interface=).

Thank you all for the answers - You’re obviously right and saved my day - I got my dst-nat working. I’ve been looking for the mistake for so long that I unfortunately skipped the /0 part.

Allow me please ressurect this thread. :slight_smile:

I have simmilar issues.. only first DST-NAT rule works. all other rules are simply not working.. not even incoming packets in statistics… but as soon i add the port to the first rule, it works. :frowning: tried to disable input filters in firewall, but no luck. :frowning: first rule is mailserver related services, others are ports for mailserver admin… just opened for my public IP at home. it’s on CCR1009-7G-1C

Post the config (/ip firewall nat export and anything related, e.g. address lists and/or interface lists) and let us examine it …