How do you read a raw NAT syslog line, field by field?

A NAT log line is two pieces stitched together. Syslog wraps an envelope around the outside with a priority, a time and a sender. The router fills the inside with the chain that matched, the protocol, and the two versions of the same session, one before translation and one after. Learn the seams and the rest is reading.

Which parts of the line belong to syslog and which to the router?

The split matters because the two halves fail separately. A wrong timestamp is a syslog problem. A missing port is a router problem. Here is a full line with the envelope still on it.

The gold part is the envelope. Everything after it came off the router as one message and syslog did not touch it.

Inside the envelope, the number in angle brackets is the priority. It carries two things packed into one integer, the facility and the severity. Divide by eight for one and take the remainder for the other. It describes the message rather than the traffic, so it is useful for sorting and useless for identification.

Then the date and time, stamped as the line left. Note what is not there. There is no year in the traditional format and no zone, which is why a store that keeps only what the line says will have trouble at the turn of a year. After that the sender name, which is whatever the router calls itself.

How does the line change with protocol?

More than people expect. The same rule produces visibly different lines depending on what crossed it, and code that assumes one shape breaks on the others.

A TCP session carries the flag that opened it, which is how you know the line marks a beginning rather than the middle of something.

UDP has no handshake, so there is no flag to print. The line is shorter and the protocol name stands alone.

ICMP has no ports at all. Nothing sits where the port numbers would be, and the position after the address is simply absent.

That last shape is the one that catches people. An address with no port is not an incomplete record of a session, it is a complete record of traffic that never had a port. Both are true at once, which is why it cannot be treated as damaged and cannot be treated as identifying either.

What does the bracketed part actually say?

It is the same session written twice. Once as it existed inside your network, once as the rest of the world saw it. The arrow inside the bracket is the translation.

On the left of the arrow, the subscriber. On the right, the address the world saw and the number the router handed that subscriber to keep them apart from everyone else on it. After the closing bracket, where the traffic was going.

The port on the right is the part people skip and the part that does the work. It is picked by the router from a range, it belongs to that subscriber for as long as the session lives, and it is reused by somebody else afterwards. A record naming the public address without that number describes a crowd.

Read the whole bracket as one fact rather than four fields. It says this private address, on this port, went out as this public address on this port. Split it up and each half means nothing on its own.

Which lines look like NAT records but are not?

Two kinds, and both arrive on the same port from the same routers, mixed into everything else.

The first is a plain filter log with no bracket. A rule with a log action writes a line whether translation happened or not, so a drop rule or an accept rule produces something that reads almost identically and carries no mapping. There is nothing in it to answer an identification question. It looks like a record and is a note.

The second is a dstnat line, which is translation running the other way. Somebody outside reached a service inside, and the router rewrote the destination rather than the source. The bracket is present and the shape is familiar, but the public address sits on the outside and the private address is the thing being written to.

Both are legitimate records of something. Neither answers the question an operator gets asked, which is always about outbound traffic and always starts from a public address that was standing in for somebody.

What in the line can mislead you?

Three fields read as more than they are.

The interface names come first. On a box with one uplink, out tells you nothing you did not know. On a box with several, it tells you which uplink was used, which changes which public address pool was in play. The same field is worthless on one router and load bearing on the next.

Then the sender name in the envelope. It is a label the router was given, not an address, and two routers can carry the same one if somebody cloned a configuration and forgot. Two devices reporting under one name produce a record that cannot be traced back to a location.

Last, the position where a subscriber name might appear. On some builds the incoming interface is the subscriber session itself, so a name sits in the line and looks authoritative. On others the same position holds a physical port shared by a whole area. The field looks identical in both cases and means something completely different.

What does a damaged line look like?

Usually it looks fine until you read the end of it. Lines travel over UDP as single messages, and a message that runs past what the path will carry arrives cut off at whatever length survived.

The front is perfect. The timestamp, the sender, the chain, the private side, all correct. The public address, which is the only reason the line existed, is not there. A store that accepts anything with a recognisable beginning will hold thousands of these and count them as records.

Two other shapes are worth knowing. A line with the bracket present but a zero in the public port position usually means the rule matched something the translation had not finished with. And a run of lines that are all identical apart from the timestamp is normally a rule matching every packet rather than the start of each session, which is a configuration problem wearing the costume of a data problem.

How can you look at these lines yourself?

Reading somebody else's example is a poor substitute for watching your own router talk. It takes a few minutes and it settles arguments that otherwise run for weeks.

Pick a machine on the same network as the router and have it listen on the port the logging action is pointed at. Any small tool that prints incoming UDP messages will do, and so will a packet capture filtered to that port if you would rather not open anything. Then generate a little traffic from a test device and watch what turns up.

Two cautions are worth stating before anybody does this on a Friday. Turning a log action on for a broad match on a live edge router produces a great deal more than expected, so start narrow, on one source address or one destination port, and widen only once you can see what a single session costs you. And do it outside your busiest hours the first time, because the honest way to find out what the volume looks like is to watch it, not to estimate it.

What you learn in ten minutes of this is which of the shapes above your own network actually produces, and that answer differs from one operator to the next.