Sorry, let me explain in more detail: DHCP packets are running smoothly on a RouterOS, this is pure DHCP server.
I want to process packets exchanged between the RouterOS and the clients, but I do not want to alter them, reading is sufficient for now. To achieve this I can:
run DHCP relay, send the packets to multiple servers (ROuterOS and my processing host) and make the topology more complex,
insert a forwarding Linux with Nftables which does what I need (duplicate packets), but this obviously is even more complex and error prone:
table ip dhcp_dup {
chain dhcp_duplicate {type filter hook prerouting priority -150;
# Duplicate inbound DHCP requests (client -> server)
udp sport 68 udp dport 67 dup to 192.168.1.247
# Duplicate DHCP traffic on standard ports
udp sport 67 dup to 192.168.1.247
udp dport 67 dup to 192.168.1.247
}
*And this NFT snipped was not tested thoroughly, i am not sure how it behaves for broadcasts.
or I can sniff the DHCP packets in the same broadcast domain, but I will be limited to only broadcsts DHCP packets from clients, I will not see server replies or unicast messages exchanged when the host already has IP.
This all takes me to the only valid solution where RouterOS is able to duplicate / mirror the DHCP packets and send them over to external host (for my own statistics and pleasure). It would be best if I could send these packages over certain interface, as I really don’t want to re-broadcast them back to same broadcast domain….
One more detail: changing the topology is not really possible, I am working with distant networks and thus I cannot introduce extra relays or linux boxes most of the time, easily.
@BartoszP this is a very good option if someone has physical access to the network. I don’t have it unfortunately, so this is dead end as RouterOS does not support, AFAIK, eg. ERSPAN.
@Guscht yes, this is more valid approach, but RouterOS sniffer encodes the traffic into TZSP. This is not widely used protocol and on my “consumer” side I would have to implement it. This is not impossible, but I am just causally looking for a simpler solution than another process (thread). And, this would be only for RouterOS, which is ~10% of the DHCP population I care about.
I will keep chasing this, and if hard pressed, will implement this TZSP, based on wiki and scarce resources in the internet (as it has no RFC or cant find valid specs……)
Ok, I implemented this TZSP protocol in my software and it works fine, but…. I fail to write any rule which would ever catch ANY UDP packet produced by the Mikrotik DHCP server
Honestly, I think that I have hit some RouterOS deficency here or I am missing some tine detail
I mean:
works: inbound packets are forwarded fine with the rule:
chain=prerouting action=sniff-tzsp sniff-target=192.168.1.247 sniff-target-port=37008 protocol=udp src-port=68 dst-port=67
(notice, earlier I made a mistake and had sniff-pc, it should have been sniff-tzsp)
does not work: any outbound packets generated by the DHCP server cannot be catched by any rule in RouterOS firewall.
/ip/firewall/mangle> print stats
Flags: D - DYNAMIC
Columns: CHAIN, ACTION, BYTES, PACKETS #CHAINACTIONBYTESPACKETS
;;; special dummy rule to show fasttrack counters
0 D prerouting passthrough 14 563 693 788 14 748 171
;;; special dummy rule to show fasttrack counters
1 D forward passthrough 14 563 693 788 14 748 171
;;; special dummy rule to show fasttrack counters
2 D postrouting passthrough 14 563 693 788 14 748 171
;;; Sniff DHCP requests to MT
3 prerouting sniff-tzsp 560 003 1 666
;;; Sniff DHCP requests from MT
4 output sniff-tzsp 0 0
;;; Sniff DHCP requests from MT
5 postrouting sniff-tzsp 0 0
;;; Sniff DHCP requests from MT
6 forward sniff-tzsp 0 0
;;; Sniff DHCP requests from MT
7 postrouting sniff-tzsp 0 0
[admin@RB5009] /ip/firewall/mangle> ..raw/print stats
Flags: X - DISABLED; D - DYNAMIC
Columns: CHAIN, ACTION, BYTES, PACKETS #CHAINACTIONBYTESPACKETS
;;; special dummy rule to show fasttrack counters
0 D prerouting passthrough 14 563 693 788 14 748 171
;;; Debug DHCP raw output
1 output log 0 0
;;; Debug ICMP raw output
2 X output log 23 612 314
IPv4 DHCP uses raw sockets, that's why you cannot catch or drop the packets on the output chain, because they are not visible to the firewall.
The DHCP processes also get the incoming IPv4 DHCP traffics before they arrive at the firewall, so dropping them to prevent the DHCP client/server from seeing them is also not possible. But at least the FW can see the inbound packets.
Just wanted to summarize limitations here, before I forget:
RouterOS cannot in any way track outbound packets as created by local DHCP server in Netfilter (or whatever ROuterOS uses). Creating any firewall rule would not reveal any outbound DHCP traffic, no matter what I did. This sounds very much as limitation, but still a feature, not a bug.
Hopefully this statement is right. Reason could be that raw sockets are used by DHCP server.
Workarounds:
RouterOS can sniff these outbound DHCP packets and sends them over TZSP protocol to a remote host. This feature works OK. TZSP allows to send the broadcasts and is generally pleasant to use. Beware: when taking about the TZSP, please note that it is a Packet Sniffer in Mikrotik, and not firewall TZSP matcher.
This TZSP matcher in firewal presumably works OK, but I suspect since Netfilter does not see any DHCP outbound packets, TSZP consequently does not forward these non-existing-for-firewall packets
I can say this is solved, hopefully this helps anyone in the future.
I guess that makes sense. I use TZSP a lot, and does make quick work of packet sniffing. One thing to watch is I believe sniffer does prevent fastpath when enabled, at least on some devices.
.
