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: src-mac , 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: src-mac , 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.
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’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 …
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 ?
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).
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:
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.
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…