There comes a port 80 request from WAN and it will be routed via the NAT-rule to the DMZ server.
But the webserver logfile has no entry that any request on port 80 came in (this sometime happens).
And then there came three ICMP requests from the same IP to the WAN port. Why the ICMP packets were tried to forward to the DMZ server?
I block several ICMP packet requests on WAN port.
But why did the RB try to forward these ICMP packets (maybe because there was an active NAT-rule before)?
Is this a kind of attack?
How can a NAT-rule/request trigger such a ICMP packet although the port 80 request does not reach the webserver (webserver-logfile)?
Type 3 Destination Unreachable [RFC792]
Code 10 Communication with Destination Host is Administratively Prohibited
Are you using a proxy service on the Mikrotik?
The traffic logged to ports 80 and 443 are going through the input chain, not the forward chain or your custom chain that is logging the three ICMP messages.
I could be reading this wrong, but it appears that the internal server has attempted to connect to the remote host, and the remote host isn’t recognizing the connections, and you’re seeing the ICMP replies from the remote host. Since the TCP handshake is never completing, this is why you wouldn’t see anything in the web server’s logs.
Ahh, I only forward port 80 and 443 and maybe the incoming http/https requests are not good (clean) enough to be forwarded. And because no forwarding rule will be used on of the last dropping rules drop the invalid packets.
So the webserver can’t write anything in the logfile.
When normal http/https requests come in the webserver also logs these requests.
I believe that the port 80 request from the screenshot were manipulated packets, so they were not be forwarded to the webserver.
UPDATE: No, the ICMP packets will be blocked by the wan1_TO_dmz2 ruleset because no rule can be used.
Maybe this behaviour of sending an ICMP in TCP/IP protocol in this situation is normal?
It seems that your dstnat pinhole rules might be wrongly configured - because if these packets reached the INPUT chain, then this means that no dstnat rule matched them to map them towards the server’s internal IP. This has nothing to do with how “clean” the connectivity is - the rules should be simple - if tcp dst-port=80, and received on the wan interface, then modify the destination IP to be the internal IP of the server.
So your clue is to find out why these packets went into the Input chain - meaning that the Mikrotik considers these packets to be directed at itself, not any pinholes or LAN-side hosts.
As for the failed ICMP, these should work as “related” connections based on the http requests that caused them to be generated… but if the Mikrotik didn’t see any outgoing packets (output or forwarded) which might have generated these ICMP replies, then the replies won’t qualify as “related” connection state, thus they get scrutinized as “new” connections would.
Ok, I also set the limit and dst-limit on my nat rules for port 80 and 443.
I thought that when Mikrotik offers these parameters, I also can use them.
But I also not found out how to reproduce this behaviour - so I believed that it is a matter of manipulated or not valid packets.
And one more thing falls on - I also log my nat rules and you can see on the first screenshot that the nat rule matched (log entry: WWW-DMZ2-HTTP dstnat…). So the dst-nat rule for port 80 matched and should be forwarded to the webserver, shouldn’t?
Okay - It’s all making a little more sense now - yes, the nat rules’ configuration can let you use rate limiting like this, but doing it this way seems to break a good design principle in my view: Keep functionality in the places that they’re intended to be implemented as much as possible.
In your case, it seems that you want to limit how many connections-per-second some host may make to the server.
This is a filtering task, not a NAT task.
NAT should be a simple map of port X → port Y, address A → address B, and so forth.
Now suppose you wanted to NAT port X → port Z for some hosts, and port Q for others, then that’s a reason to add more criteria such as src-address, or rate limiting, etc… but if you just want to BLOCK after X amount of connections, it makes more sense to put a filter rule which does this task.
So make the dstnat rule very simple: map 80,443 to the server, k-thanks-bye.
Then make the filter rule say:
Okay, so long as they’re below some threshold, they’re allowed in.
What? They exceeded the threshold - throw the new connection attempts into the trashcan!
yeah, but in theory - he also may use some other things i nat aswell.
among popular/generic things are: apply portrange limitation to masquerading(usually done in ISP CPE, care to filter or atleast throttle “lower”/highsec ports, eg first 1024 for example), change TTL, tweak MSS, strip IPv4 options and few others.
That the nat rule will be inactive when the limits of this rule are reached and the packets goes to the input chain, is not a good design principle but why does Mikrotik allow limits on nat rules?
You could possibly use it in some other way, such as load balancing between a pool of internal servers, for instance. The rate limit matcher is just a tool, like a jigsaw, which is great for cutting holes in wood, but really lousy for painting your garage…
