How does NAT logging work on a MikroTik router?

A MikroTik router does not record address translation on its own. You have to ask for it. A firewall rule marks the traffic worth writing down, a logging action pushes the resulting lines off the router, and what lands at the other end is one line per session carrying both the private address and the public address it went out on.

What does the router actually record when it translates an address?

Nothing, unless told to. The router holds the mapping in connection tracking while the session is alive, uses it to send replies back to the right subscriber, and drops it when the session ends. That table lives in memory. Reboot the router and it is gone, and so is any way of saying who was behind an address ten minutes ago.

This surprises people. Translation and logging feel like the same job, and on the router they are not related at all. The nat table rewrites the address because that is what keeps the network working. Writing a line about it serves nobody on the router itself, so RouterOS does not do it.

The record only starts existing when a rule in the filter table matches the traffic and its action is set to log. Everything after that, where the line goes and how long it survives, is a separate set of choices.

What the rule matches decides whether the whole thing is usable or unusable. A rule that catches every packet produces a line for each one, and a single video call can run to thousands of them, all saying the same thing about the same session. Matching only the packet that opens a connection gives one line per session, which is the unit anybody asking questions later actually cares about.

That single decision is the difference between a store you can search and a store you cannot afford to keep. It also keeps the router quieter, because the logging work happens once per session rather than once per packet.

Why does a NAT log line need to exist at all?

Because the public address on its own points to nobody. Hundreds of subscribers share one address at the same time. An outside party sees only that address and a port, and the only thing that ties the two together is a record made at the moment of translation.

The question usually arrives long after the traffic did. Somebody sends an address, a port and a timestamp, and asks who was using it. Without a stored line there is no honest answer, and a router that was rebooted last month cannot help either.

Port numbers matter more than people expect. Two subscribers on the same public address at the same second are told apart only by the port the router picked for each of them. A record that carries the address but not the port narrows the answer to a few hundred people, which is the same as no answer.

The sharing gets heavier every year. Networks that ran out of public addresses moved subscribers onto shared space behind the edge router, so traffic now passes through translation twice before it reaches the internet. More subscribers stand behind each public address than they did five years ago, and the record made at the edge is the only thing that separates them.

Where does the router send these lines?

RouterOS separates what to log from where it goes. Topics are matched by rules, and each rule points at an action. Three targets are built in and they behave very differently once real volume starts moving.

The three places RouterOS can put a log line

Target	What happens	Where it falls down
Memory	Lines sit in RAM and can be read from the log window	Fixed number of lines, oldest overwritten, empty after a reboot
Disk	Lines are written to a file on the router	NAT volume wears out the built in flash, and space is measured in megabytes
Remote	Lines are pushed over syslog to another machine	Needs a second machine that stays reachable and powered

MikroTik is direct about this in its own documentation. High frequency topics such as firewall should not go to the internal storage because of flash wear, and a remote target is what it points you at instead. NAT logging on a live network is about as high frequency as it gets.

The remote action carries an address and a port. UDP 514 is the standard, and any other UDP port works if that suits the network better. From that point the router stops caring. It sends and forgets, which is worth knowing before you build anything around it.

What is inside one line, field by field?

One session produces one line, and the whole answer is inside it. Here is the shape it arrives in, with the two addresses marked.

Reading it from the left, forward is the chain that matched, and in and out name the interfaces the packet came from and left by. proto gives the protocol, with the flag that opened the session in brackets.

Then the pair that matters. The first address and port is the subscriber before translation. The part in brackets after NAT shows the same session again, this time with the public address and the port the router assigned to it. The address after the closing bracket is where the traffic was headed.

So a line contains four things worth keeping. Who, in the form of a private address. What they reached. The public address and port that stood in for them. And the moment it happened, which syslog stamps on the front as the line leaves the router.

One thing is missing from that list and its absence causes most of the work later. The subscriber name is not in the line. The router writes an interface, not a person.

What does the router not keep track of on its own?

Three things, and none of them are faults. They are simply outside what a router is for.

1. The identity behind the address. Unless the session arrives on an interface named after the subscriber, the line carries an interface and nothing more, and matching that back to a person happens elsewhere.
2. Anything that came before this instant. There is no history on the router, only the sessions currently open.
3. How long records should be held. Retention is a policy that lives wherever the lines are stored, and the router has no opinion on it.

Clock accuracy belongs in the same conversation. Every line is stamped by the router, and a router with a drifting clock produces records that cannot be lined up with anybody else's. Time synchronisation is a two minute job that quietly decides whether a year of records is usable.

What breaks a NAT logging setup?

Usually one of five things, and four of them are silent. Logs stop arriving and nothing announces it.

Rule order comes first. The filter table is read from the top down, and anything that accepts or fasttracks a connection before your log rule means those packets never reach it. A rule that looks correct in isolation can sit below something that has already ended the conversation.

Then the firewall between the router and the collector. Syslog leaves on UDP, and a rule that blocks that port in either direction drops every line without complaint.

Third, the address of the collector. If the machine receiving the logs changes address, the router keeps sending to the old one. There is no error, because UDP does not expect a reply.

Fourth, disk space at the far end. NAT records grow steadily and a full disk stops the collection the same way an unplugged cable would.

The fifth is the one people underestimate. Nobody checks. A logging setup can be silently dead for weeks, and the day it is noticed is usually the day somebody asks for records that were never written.