I’m fairly new to mikrotik (I’m testing 7.11 on an RB5009 right now), but spent many years with other commercial platforms like fortinet and cisco. I’m currently having trouble figuring out why my Masquerade rule doesn’t fire when I use interfaces as my match criteria. Whenever I had packets not going where I wanted, I usually resorted to debugging the packet flow through the firewall rules to see where I messed up on the rule matching (or if something else was grabbing it first). I’ve tried to follow the information on the LOG help page, but I’m at a loss of how to find or see the firewall processing decisions based on the chains or any other rules. Here’s some things that i’m trying to answer, please help a newbie help themself.
Should it be as simple as saying I want to see the logs for “firewall, debug” either in memory or my own action to keep it separate?
I see it mentions OSPF has several log topics, is there a way to see all that the firewall would use since it seems like I’m missing something?
Is there a deeper way of doing this on the console/terminal?
Concerning logging, you first need to create an “action” which is roughly a “logs destination”. You name it freely and decide where you want it to log (memory, echo, remote, disk, email), and how much you want to log (#lines, knowing that if you do not select stop when full it discards older lines). Then you “subscribe” to topics. For instance if you select “firewall, debug” topics and a new action “mylogs” with “memory” target, all events matching both topics “firewall” and “debug” will trigger your “mylogs” action, i.e. log to memory.
For the list of topics, you can find it by using command completion in terminal:
I do no understand “deeper way”, can you please elaborate ?
Hope it helps,
K.
Edit: if you’re looking for a command/way to mark a packet and log “how the hell this packet ended arriving here, please print the processing decisions” I’m afraid there is no such option (I am aware of).
Yeah, that’s exactly what I was meaning. here’s what I’d do on the fortigate: debug packet flow
something like “diagnose debug flow filter addr 1.1.1.1” would let me see all IP packets with the 1.1.1.1 address in it. Then with extra flags I could see it match or not match all existing firewall rules in the tables as it flows through checking.
I guess follow-up question then; if I think I’m hitting a bug on NAT masquerade where it doesn’t match based on the outbound interface (or int list), what would be the best way to prove or disprove that it’s not a configuration error somewhere else in my system? I’ve tried reducing the rules to basically just the Masquerade action and no other filter rules, but the only way I’ve gotten it to work is if there’s no other criteria except by using IP addresses or lists.
I wish I had such a tool on Mikrotik’s RouterOS (if it exists please someone tell us!)
You can try to play around with “/tool/sniffer” and “/tool/torch”, it can help you detect the packets, but you won’t be able to set the “extra flags” you’re used to.
I would first gather as much information as possible, export my configuration, describe a simple use case, draw a minimal network diagram and would post it on this forum in a new thread. Then based on the outcome of the discussion (maybe it’s a bug, maybe it’s something you’re not used to as you’re new to RouterOS) I would then fix my configuration or open a support ticket on Mikrotik website to describe the bug and would point to the thread where the discussion was happening.
You can add a log option to a rule in the firewall to log when it matches, or you can add an extra “log” rule with the appropriate matching criteria (in this case an address, but it can be anything) and when it matches it will log the appropriate message.
The default logging configuration will show those messages in the logging window, but of course you can change that.
This allows you to log the packet based on some conditions once it gets somewhere, but does not allow you to display how he flew up to this point (read the link OP provided)
Comment: SYN packet received:
id=20085 trace_id=209 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
SYN sent and a new session is allocated:
id=20085 trace_id=209 func=resolve_ip_tuple line=2799
msg="allocate a new session-00000e90"
Lookup for next-hop gateway address:
id=20085 trace_id=209 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.11.254 via port6"
Source NAT, lookup next available port:
id=20085 trace_id=209 func=get_new_addr line=1219
msg="find SNAT: IP-192.168.11.59, port-31925"
direction“
Matched security policy. Check to see which policy this session matches:
id=20085 trace_id=209 func=fw_forward_handler line=317
msg="Allowed by Policy-3: SNAT"
Apply source NAT:
id=20085 trace_id=209 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
SYN ACK received:
id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6, 203.160.224.97:80-
>192.168.11.59:31925) from port6."
Found existing session ID. Identified as the reply direction:
id=20085 trace_id=210 func=resolve_ip_tuple_fast line=2727
msg="Find an existing session, id-00000e90, reply direction"
Apply destination NAT to inverse source NAT action:
id=20085 trace_id=210 func=__ip_session_run_tuple
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
Lookup for next-hop gateway address for reply traffic:
id=20085 trace_id=210 func=vf_ip4_route_input line=1543
msg="find a route: gw-192.168.3.221 via port5"
ACK received:
id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2700
msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
id=20085 trace_id=211 func=resolve_ip_tuple_fast line=2727
msg="Find an existing session, id-00000e90, original direction"
Apply source NAT:
id=20085 trace_id=211 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from client:
id=20085 trace_id=212 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
192.168.3.221:1487->203.160.224.97:80) from port5."
Match existing session in the original direction:
id=20085 trace_id=212 func=resolve_ip_tuple_fast
line=2727 msg="Find an existing session, id-00000e90, original direction"
Apply source NAT:
id=20085 trace_id=212 func=__ip_session_run_tuple
line=1502 msg="SNAT 192.168.3.221->192.168.11.59:31925"
Receive data from server:
id=20085 trace_id=213 func=resolve_ip_tuple_fast
line=2700 msg="vd-root received a packet(proto=6,
203.160.224.97:80->192.168.11.59:31925) from port6."
Match existing session in reply direction:
id=20085 trace_id=213 func=resolve_ip_tuple_fast
line=2727 msg="Find an existing session, id-00000e90,reply direction"
Apply destination NAT to inverse source NAT action:
id=20085 trace_id=213 func=__ip_session_run_tuple
line=1516 msg="DNAT 192.168.11.59:31925-
>192.168.3.221:1487"
I explained what is available in RouterOS. What he knows from other platforms is not available. No need to discuss that any further.
I should say once you understand the packet flow (at least in general) in RouterOS it is not required to trace the entire flow, you immediately know which rules the packet is going to go along and where you need to put your log rules.
It also helps when you have experience with Linux (as it is the underlying platform).
Wiki tells me “Tazman Sniffer Protocol”. But since it was originally a cisco protocol, and they have many offices as on a street called “Tasman”, so wiki may not be right IMO.
(if it exists please someone tell us!)