Hi guys,

we are a little WISP in Italy, we need to log all traffic, we do with this script:

/system logging action
set 3 bsd-syslog=yes remote=192.168.13.2 src-address=192.168.13.1
add bsd-syslog=yes name=SendToSyslog remote=192.168.13.2 src-address=192.168.13.1 syslog-facility=local1 target=remote
/system logging
set 0 disabled=yes
set 1 topics=error,!ovpn
add action=remote topics=info
add action=SendToSyslog prefix=LogUsers topics=firewall
add action=disk topics=info,!firewall


/ip firewall mangle
add action=log chain=forward comment="Log Dstr A" connection-state=new log-prefix="Dstr A" src-address=ip_private_A/24
add action=log chain=forward comment="Log Dstr B" connection-state=new log-prefix="Dstr B" src-address=ip_private_B/24

and so on ...

The problem is that when we get the email for infringement of copyright sometimes we are able to find the connection, sometimes no!!
The strange thing is that on log we find some entries like:
forward:<interface> src-mac <macaddress>, proto TCP (SYN), ip_private:portA -> ip_public:portB, len 52
In this case where is the NAT translation log? No way to find the NAT neither looking for ip_private_portA before this entry.

If the email comes from companies like that, may ok if we do not find the connection, the problem is when police will require this info ...

Please help!!

What is the configuration you use in order to log all the traffic? Are you able to identify all the connections?

The problem is that when we get the email for infringement of copyright sometimes we are able to find the connection, sometimes no!!
The strange thing is that on log we find some entries like:
forward:<interface> src-mac <macaddress>, proto TCP (SYN), ip_private:portA -> ip_public:portB, len 52

are you using fasttrack?

Regarding that odd entry, how is your masquerade setup? By outgoing interface and src-address?

you should block traffic between the two wan interfaces.

IMHO if you are a (W)ISP is better to use Traffic Flow and ELK stack for these duties.

We do not use fasttrack, at least we have no rules set as action=fasttrack ....

The masquerading is like:
/ip firewall nat
add action=src-nat chain=srcnat comment="srcnat Users" out-interface=ether4 src-address=private_subnetA/24 to-addresses=public_ipA
add action=src-nat chain=srcnat comment="srcnat Users" out-interface=ether4 src-address=private_subnet_B/24 to-addresses=public_ipB

As far as I know Traffic Flow is for statistics, right? How can I use that for logs ?

Drop connection-state=invalid in the firewall chain forward.

NAT works only with connections, if connection tracking entry is not there for particular packet NAT doesn't apply, it is been like this since RouterOS v2.9.x

As far as I know Traffic Flow is for statistics, right? How can I use that for logs

Traffic flow sends a summary of network traffic, it includes source and destination ips, even nat details.

Drop connection-state=invalid in the firewall chain forward.

NAT works only with connections, if connection tracking entry is not there for particular packet NAT doesn't apply, it is been like this since RouterOS v2.9.x

I have that rule but the point is not that.

I'm sure that the connection was ok because I have received notification from the external company. The problems is that there is no trace in the log about that connection !
I do not have idea why a NAT shouldn't be applied on a verified connection.
I mean, since I'm sure that the client has downloaded the file, there was a connection so for sure that packet hits the NAT ! The log should have registered the connection ...

As far as I know Traffic Flow is for statistics, right? How can I use that for logs

Traffic flow sends a summary of network traffic, it includes source and destination ips, even nat details.

Ok, but I do not think this is the solution. There must be another way to collect only the connections !
Are you a (W)ISP ? Do you use only Traffic Flow to collect users log ?
Are you so kind to share the configuration script and schema ?

Anyway, thank you for your help!

Maybe I have found the problem.
Should the log action be set in /ip firewall filter instead of /ip firewall mangle?

no suggestions?

Yes, I have implemented that solution on several WISPs.

I am afraid it's not as simple as a script, ELK (Elasticsearch, Logstash and Kibana) is an ecosystem on its own, but very worth the effort to learn to monitor and analyze (W)ISP traffic offline.

Regarding wether to use IP firewall Rules or mangle to log, AFAIK it shouldn't make a difference per se as long as the proper chain is used (as you did), though mangle isn't the place where I'd intuitively put it, but at the end of filter rules.

Do you have QoS in place that guarantees smooth mikrotik ->syslog server communication? Bear in mind syslog uses UDP so logs can be missed on congested scenarios and that could be the cause of missing logs.

Thank you for your help.
I spent all the afternoon looking at the logs trying to find the problem .
I can confirm that mangle or filter is the same, I get exactly the same log entries. I even tried to enable the log on NAT rules, the entries were the same.

At the end, I removed the check on connection-state=new and the "old" "short"entries like:
TCP (or UDP) ip_private:A -> ip_dst_public:B
became more and like:
TCP (or UDP) ip_private:A NAT my_ip_public:A -> ip_dst_public:B

So, I suppose that the end of the story is:
when I get request from authorities (or external companies because of copyright) I should use as search parameter the ip_private_subnet:port_number instead of my_ip_public:port_number (because all NAT extension is omitted).

Can you confirm my supposition?

The difference between having state new ticked or not is if ticked, only the first packet sent by the internal customer will be logged; the rest of packets traversing that connection will have states related or established so won't be matched nor logged.

By unticking state new ALL packets from that connection will be logged, if that's what you want (check load and syslog usage).

RouterOS doesn't change the original addresses in the logs.

Try this rule as the last of your forward chain ruleset:
You should see entries like (INTERNET is the internet interface)
So all the info of the connection is there.

When looking for a connection, I'd search first for the Internet IP that was accessed, then work backwards to see who was...

I would think that logging action on the NAT rule would be the best place - the NAT rule naturally only happens whenever a new connection is made, and must be triggered once for each new connection, so give that a shot to see how it works for you.

I would think that logging action on the NAT rule would be the best place - the NAT rule naturally only happens whenever a new connection is made, and must be triggered once for each new connection, so give that a shot to see how it works for you.

I did.
If you enable the log action in srcnat rule, in the syslog you'll obtain the same situation like log connection-state=new.

The difference between having state new ticked or not is if ticked, only the first packet sent by the internal customer will be logged; the rest of packets traversing that connection will have states related or established so won't be matched nor logged.

This is clear. What surprise me is that if I look for a specific port I am able to find the entry like:
192.168.10.199:62349 -> 112.198.118.103:60241

but nothing about the first NAT packet ! I thought that there should be because when the client tries to establish a connection on a different port is a new connection, so the first packet should be captured and sent to log.

When looking for a connection, I'd search first for the Internet IP that was accessed, then work backwards to see who was...

ok !