Packets on INPUT chain blocked when translated.

RouterOS General
1

I’m trying to understand why I’m seeing this:

08:49:07 firewall,info input: in:public-gateway out:(none), src-mac 44:f4:77:10:ba:20, proto TCP (ACK,FIN), 6.1.1.2:62092->6.16.9.6:443, len 52

When I have this:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=6.16.9.6 dst-port=443 protocol=tcp to-addresses=192.168.10.6

According to the packet flow https://wiki.mikrotik.com/wiki/Manual:Packet_Flow the packet should show up on the input interface, hit the pre-routing chain (dst-nat) then hit the forward chain because we are translating the destination to 192.168.10.6.

Any ideas why this packet would hit the INPUT chain and not the FORWARD chain?

2

More oddness:

If I trace a flow using logging in the prerouting or post routing chain I see something like this:

Where 1.1.1.1 is the public client, 2.2.2.2 is the public facing address on the routeros host, and 3.3.3.3 is the private address I’m doing port address translation to:

Mar 30 12:26:32  prerouting: in:pub out:(none), proto TCP (ACK), 1.1.1.1:61424->2.2.2.2:443, NAT 1.1.1.1:61424->(2.2.2.2:443->3.3.3.3:443), len 40
Mar 30 12:26:32  postrouting: in:(none) out:priv, proto TCP (ACK), 1.1.1.1:61424->3.3.3.3:443, NAT 1.1.1.1:61424->(2.2.2.2:443->3.3.3.3:443), len 40
Mar 30 12:26:37  prerouting: in:pub out:(none), proto TCP (ACK), 1.1.1.1:61424->2.2.2.2:443, NAT 1.1.1.1:61424->(2.2.2.2:443->3.3.3.3:443), len 52
Mar 30 12:26:37  postrouting: in:(none) out:priv, proto TCP (ACK), 1.1.1.1:61424->3.3.3.3:443, NAT 1.1.1.1:61424->(2.2.2.2:443->3.3.3.3:443), len 52
Mar 30 12:27:15  prerouting: in:pub out:(none), proto TCP (ACK,FIN), 1.1.1.1:61424->2.2.2.2:443, len 40
Mar 30 12:27:15  input: in:pub out:(none), proto TCP (ACK,FIN), 1.1.1.1:61424->2.2.2.2:443, len 40
Mar 30 12:27:15  input: in:pub out:(none), proto TCP (ACK,FIN), 1.1.1.1:61424->2.2.2.2:443, len 40
Mar 30 12:27:16  prerouting: in:pub out:(none), proto TCP (ACK,FIN), 1.1.1.1:61424->2.2.2.2:443, len 40
Mar 30 12:27:16  input: in:pub out:(none), proto TCP (ACK,FIN), 1.1.1.1:61424->2.2.2.2:443, len 40

As you can see for a while we translated the packet just fine, and they hit the forward table, then suddenly we don’t translate anymore and the traffic hits the INPUT chain. Looks like the session is over because they are all flagged FIN, but my dst-nat rule doesn’t care about state:

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=2.2.2.2 dst-port=443 protocol=tcp to-addresses=3.3.3.3

I’m wondering how this affecting my services… Any ideas?

3

Dstnat rules work for connections, not for individual packets (if you connect to forwarded port once, you only see counter increased by one, even though there are more packets coming). If conntrack thinks that connection ended, it won’t forward further packets. And ACK,FIN ones probably don’t count as new connection for conntrack. I can’t say for sure, but I’d expect them to have invalid connection state. If you don’t have a rule like this, try to add it and see if it catches them:

/ip firewall filter
add action=drop chain=input connection-state=invalid
4

Thanks for the response. You are right, they are invalid packets, because the tcp timeout on connection tracking is super aggressive. I relaxed that a bit and that helped, now I’m dropping invalid traffic before it hits my logs so that I’m not filling up my firewall logs with tcp timeout nonsense.

Again, thank you for for the help…

schu