Firewall dropping incoming packets for srcnat by the input chain.

We have a new RB3011UiAS, version 6.33.5

The networks is very simple: we have one fixed wan address, and the local network is 10.0.0.0/24
We sightly modified the default configuration:

  • we allow smtp inbound connection on port 25, with dstnat. That’s all.

So the firewall opened outbound without restriction, for inbound only smtp allowed.

The NAT rules:

Flags: X - disabled, I - invalid, D - dynamic
0 ;;; default configuration
chain=srcnat action=masquerade out-interface=ether1-gateway log=no log-prefix=“”
1 ;;; Port forwarding SMTP to email server
chain=dstnat action=dst-nat to-addresses=10.0.0.2 to-ports=25 protocol=tcp in-interface=ether1-gateway dst-port=25 log=no log-prefix=“”

The Filter rules:

0 D ;;; special dummy rule to show fasttrack counters
chain=forward
1 ;;; default configuration
chain=input action=accept protocol=icmp log=no log-prefix=“”
2 ;;; default configuration
chain=input action=accept connection-state=established,related log=no log-prefix=“”
3 ;;; default configuration
chain=input action=drop in-interface=ether1-gateway log=yes log-prefix=“dropped”
4 ;;; default configuration
chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=“”
5 ;;; default configuration
chain=forward action=accept connection-state=established,related log=no log-prefix=“”
6 ;;; default configuration
chain=forward action=drop connection-state=invalid log=no log-prefix=“”
7 ;;; default configuration
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1-gateway log=no log-prefix=“”

The problems is that we see that filter rule 3. dropping some packets for a srcnat connection:

07:50:44 firewall,info dropped input: in:ether1-gateway out:(none), src-mac 00:25:2e:0e:33:77, proto TCP (ACK), 217.110.97.197:80->[our wan ip]:50609, len 40
07:52:15 firewall,info dropped input: in:ether1-gateway out:(none), src-mac 00:25:2e:0e:33:77, proto TCP (RST), 216.58.209.174:80->[our wan ip]:55436, len 40

All of the above dropped packets by the input chain is related to an existing legit srcnat connection.

I don’t understand this, what is wrong with rule 3? Why it drops incoming packets for a masquarde srcnat connection?

I would move rule #3 down to around rule #6. Rule #3 should not be effecting this traffic, it should be hitting a forward accept/deny rule. You want all of your accepts above any deny rule that is not very specific. See if that helps.

Input / Output chains are for the Mikrotik itself, not for any packets passing through the router to other hosts.
USe the FORWARD chain to allow traffic through a NAT pinhole.

/ip firewall filter add chain=forward action=accept connection-nat-state=dstnat

This one rule will allow all of your pinholes (if you ever add more, they’ll also match this one rule)

As Revelation said - put this rule after the connection-state=established,related rules, but before the default drop action.

Moving firewall rules has no effect.
I added an extra rule to drop and log invalid incoming packets:

chain=input action=drop connection-state=invalid log=yes log-prefix=“invalid”

Also enabled log on the forward rules.

Examined the log and found this:

  • The connection is a simple http connection started by some LAN client to some public server.
  • The incoming traffic from the public server correctly nated back to the LAN client.
  • But some packets in the incoming traffic marked as invalid by mikrotik and so dropped.

Why mark routeros some of these packets as invalid? Is this a routeros bug?

Found this:
http://forum.mikrotik.com/t/connection-tracking-timeout-values/77167/1
and this:
http://forum.mikrotik.com/t/lot-of-packets-being-dropped-due-to-invalid-connection/17948/1

I increased the timeouts, but still get the some amount of invalid packets.
Most of the invalid packets are RST, or ACK/FYN for an already discarded nat connection.
Maybe this is normal, but I’m not sure.

That is not a bug … unless You got broken router or broken memory in router

that is normal botnet activity
they got You adress and trie to log or find open ports or hack you to make You zombie part of they network

Just make sure You block everything and make several rule for White connection
like estabilished and related rule

Then … every connection started from You network will be fine
and every connection to You ip adress (not exacly adressed … invalid and unknown) will be droped

That is the reason i guess, i had a broken router. Just got it replaced with a new one.