Dear All,
I am using firmware 7.17 on routerboard model RB750Gr3 with firmware type mt7621L
In my case the output interface can have the following values in the log: out:(unknown 0),
out:ether1_gw,
out:bridge1,
It is possible to find a groc pattern: out:([a-zA-Z0-9:_ ()]+),
but it’s not possible to put this into a variable in elastic search
It would be great if out:(unknown 0), would become for example out:unknown:0, or similar.
The other question is, why is this interface unknown ? This happens primary when a rule drops a packet. Therefore a packet doesn’t leave the FW and there is no outgoing interface. In this case a simple “na” for not available would be fine. But this is not for all rules so. I have drop rules where an dedicated out interface is listed. So why is this interface listed when the dropped packet does not pass this interface ?
Because egress interface is not known when FW drops connection/packet. Why? It depends on rule itself and L3 networks layout on your router. So without knowing that and full log line it’s impossible for us to tell.
BTW, what’s your reason to bother about dropped connections/packets? Unless you’re troubleshooting some weird behaviour it’s IMO waste of time and computing resources (bot router and log server).
Hi mkx !
Many thanks for your swift answer. It’s far away that I want to bother you or the system. This mikrotik router is a great product. But even great products can be improved.
My intention is to have a most complete firewall log because it is IMO important for analysing.
For example this is a log for a rule where the packet is dropped and the out interface is listed
Feb 3 11:42:56 mikrotik1 v4_drop_4r437_fwdlast forward: in:ether1_gw out:bridge1, connection-state:new,dnat src-mac 20:83:f8:a2:74:f2, proto UDP, 204.76.203.80:2842->192.168.241.190:123, NAT 204.76.203.80:2842->(x.y.z.a:123->192.168.241.190:123), len 36
I removed the public IP by x.y.z.a
This is the related rule
add action=drop chain=forward comment=
“v4_drop_4r437_fwdlast / End Of Forward (Drop)” log=yes log-prefix=
v4_drop_4r437_fwdlast
and this is an example where the out interface is unkown
Feb 3 11:43:03 mikrotik1 v4_drop_4r409_in_TCP input: in:ether1_gw out:(unknown 0), connection-state:new src-mac 20:83:f8:a2:74:f2, proto TCP (SYN), 213.32.32.90:43277->x.y.z.a:4544, len 60
this is the config
add action=drop chain=input comment=
"v4_drop_4r409_in_TCP / End of Input / Drop " log=yes log-prefix=
v4_drop_4r409_in_TCP protocol=tcp
If you need more information then I am happy to share with you.
With logging I have another recommendation or lets say a wish I want to tell you. In the log we can’t see the action. For example accept, reject or drop. For a firewall it is essential if a packet can pass or not. I managed in my working live several firewalls of different vendors but I did never have the situation that the action was not listed in the logs. Maybe there is anywhere a switch in setup to change this behaviour which I do not know. Then be so kind and tell me where to look.
Feb 3 11:42:56 mikrotik1 v4_drop_4r437_fwdlast > forward> : in:ether1_gw out:bridge1, connection-state:new,dnat src-mac 20:83:f8:a2:74:f2, proto UDP, 204.76.203.80:2842->192.168.241.190:123, NAT 204.76.203.80:2842->(x.y.z.a:123->192.168.241.190:123), len 36
Feb 3 11:43:03 mikrotik1 v4_drop_4r409_in_TCP > input> : in:ether1_gw out:(unknown 0), connection-state:new src-mac 20:83:f8:a2:74:f2, proto TCP (SYN), 213.32.32.90:43277->x.y.z.a:4544, len 60
Maybe I am reading this wrongly but the chain input should not have an out interface, while the chain forward should (possibly in some cases the out will be unknown in forward as well? ).
I just upgraded to OS 7.18.1
And I saw the possibility to change in log action the remote log format for firewall to CEF. I also add a CEF delimiter. Obviously this doesn’t have any effect as it doesn’t appear in the log.
Generally the change hasn’t brought a big advantage. Different FW rules are still producing different log formats and it is still complex to parse it as before.
).