Latest version ndpi-netfilter detection is "Unknown",but ndpiReader can detection is Mining [4.3.0-3719-a05def54(flow_info-4)]

[someonebw]

hi,vel21ripn

It's a great project
Thank you for your hard work to bring us a good combination of applications

I have a question I'd like to ask you

my nat server
ens33---out to wan
ens36---out to lan

#Kernel version
[root@local-nat-server example]# uname -ar
Linux local-nat-server 5.10.4-1.el8.ndpi.x86_64 #1 SMP Fri Apr 15 08:58:54 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux

#ndpi-netfilter version is 4.3.0-3719-a05def54(flow_info-4)
[root@local-nat-server tests]# cat /proc/net/xt_ndpi/proto |more
#id mark ~mask name # count #version 4.3.0-3719-a05def54

//load mod command
//modprobe xt_ndpi xt_debug=3 lib_trace=4 ndpi_enable_flow=1

#51.15.119.157 is about Mining server's ip
[root@local-nat-server tests]# cat /proc/net/xt_ndpi/ip_proto |grep 51.15.119.157
51.15.119.157 Mining

i have a test for identify mining protocol
client do some test command ：
ping 51.15.119.157
curl http://51.15.119.157
curl https://51.15.119.157

but in nat server ,i see the flow , mining protocol is 0 ?
(use ndpi_flow_dump to see) and
[root@local-nat-server example]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3

#in flow this protocol is "Unknown"
Every 1.0s: ./ndpi_flow_dump -s local-nat-server: Sat Apr 16 04:20:29 2022
TIME 1650097229
1650097228 1650097228 4 6 192.168.32.129 53596 51.15.119.157 80 60 0 1 0 I=3,0 SN=192.168.1.182,53596 P=Unkno
wn

bu when i use ndpiReader see that pcap file ,And it turns out you can recognize it,

#pcap file cap in client
[root@local-nat-server example]# ./ndpiReader
Welcome to nDPI 4.3.0-3719-a05def54

[root@local-nat-server example]# ./ndpiReader -i ens36.pcap |grep Mining
Mining packets: 6 bytes: 444 flows: 2
[root@local-nat-server example]# ./ndpiReader -i ens36.pcap -v 2|grep Mining
Mining packets: 6 bytes: 444 flows: 2
5 TCP 192.168.32.129:49164 -> 51.15.119.157:443 [proto: 91.42/TLS.Mining][Encrypted][Confidence: Match by IP][cat: Mining/99][3 pkts/222 bytes -> 0 pkts/0 bytes][Goodput ratio: 0/0][3.06 sec][Risk: ** Unsafe Protocol **][Risk Score: 10][Plen Bins: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
6 TCP 192.168.32.129:53568 -> 51.15.119.157:80 [proto: 7.42/HTTP.Mining][ClearText][Confidence: Match by IP][cat: Mining/99][3 pkts/222 bytes -> 0 pkts/0 bytes][Goodput ratio: 0/0][3.06 sec][Risk: ** Unsafe Protocol **][Risk Score: 10][Plen Bins: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

###debug info in messages
#curl http://51.15.119.157
Apr 16 03:57:54 local-nat-server kernel: START target ct_ndpi 000000007177773a ct 000000004ed06f47 proto 6 192.168.32.129:53594 -> 51.15.119.157:80 DIR
Apr 16 03:57:54 local-nat-server kernel: Reuse ct_ndpi 000000007177773a ct 000000004ed06f47 proto 6 192.168.32.129:53594 -> 51.15.119.157:80 DIR
Apr 16 03:57:54 local-nat-server kernel: START match skb 00000000d500d4ab ct 000000004ed06f47 proto 6 192.168.32.129:53594 -> 51.15.119.157:80 len 60 [0,0,Match by IP] DIR
Apr 16 03:57:54 local-nat-server kernel: cached dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
Apr 16 03:57:54 local-nat-server kernel: cache skb 00000000d500d4ab ct 000000004ed06f47 proto 6 192.168.32.129:53594 -> 51.15.119.157:80 len 60 [0,0,Match by IP]
Apr 16 03:57:54 local-nat-server kernel: inprogress dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
Apr 16 03:57:54 local-nat-server kernel: ndpi_tg:ns0 flow_yes flow_nat 2

###debug info in messages
#curl https://51.15.119.157
Apr 16 03:06:02 local-nat-server kernel: START match skb 0000000027e6501f ct 000000009f803943 proto 6 192.168.32.129:49148 -> 51.15.119.157:443 len 60 [0,0,Match by IP] DIR
Apr 16 03:06:02 local-nat-server kernel: ndpi: ct_ndpi pK-error counter pkt 1 bytes 60
Apr 16 03:06:02 local-nat-server kernel: process skb 0000000027e6501f ct 000000009f803943 proto 6 192.168.32.129:49148 -> 51.15.119.157:443 len 60 [0,0,Match by IP]
Apr 16 03:06:02 local-nat-server kernel: ndpi_process_packet guessed proto 91 host_proto 42, master 0, app 0, Match by IP
Apr 16 03:06:02 local-nat-server kernel: ndpi dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
Apr 16 03:06:02 local-nat-server kernel: inprogress dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
Apr 16 03:06:02 local-nat-server kernel: match_done skb 0000000027e6501f ct 000000009f803943 proto 6 192.168.32.129:49148 -> 51.15.119.157:443 len 60 [0,0,Match by IP] result 1
Apr 16 03:06:02 local-nat-server kernel: Reuse ct_ndpi 00000000324aba29 ct 000000009f803943 proto 6 192.168.32.129:49148 -> 51.15.119.157:443 DIR

##parameters
[root@local-nat-server log]# grep . /sys/module/xt_ndpi/parameters/*
/sys/module/xt_ndpi/parameters/bt6_hash_size:0
/sys/module/xt_ndpi/parameters/bt_gc_count:0
/sys/module/xt_ndpi/parameters/bt_hash_size:0
/sys/module/xt_ndpi/parameters/bt_hash_timeout:1200
/sys/module/xt_ndpi/parameters/bt_log_size:128
/sys/module/xt_ndpi/parameters/cached:124190
/sys/module/xt_ndpi/parameters/c_last_ct_not:0
/sys/module/xt_ndpi/parameters/c_magic_not:125201
/sys/module/xt_ndpi/parameters/ct_confirm:0
/sys/module/xt_ndpi/parameters/ct_ndpi:0
/sys/module/xt_ndpi/parameters/ct_nolabel:0
/sys/module/xt_ndpi/parameters/ct_null:92846
/sys/module/xt_ndpi/parameters/ct_untrack:0
/sys/module/xt_ndpi/parameters/err_add_ndpi:0
/sys/module/xt_ndpi/parameters/err_alloc_flow:0
/sys/module/xt_ndpi/parameters/err_alloc_id:0
/sys/module/xt_ndpi/parameters/err_bad_tcp_udp:0
/sys/module/xt_ndpi/parameters/err_ip_frag_len:0
/sys/module/xt_ndpi/parameters/err_noiphdr:0
/sys/module/xt_ndpi/parameters/err_oversize:0
/sys/module/xt_ndpi/parameters/err_prot_err:0
/sys/module/xt_ndpi/parameters/err_skb_linear:0
/sys/module/xt_ndpi/parameters/flow_created:3696
/sys/module/xt_ndpi/parameters/flow_deleted:3692
/sys/module/xt_ndpi/parameters/flow_read_debug:0
/sys/module/xt_ndpi/parameters/id_num:0
/sys/module/xt_ndpi/parameters/ipv4:342233
/sys/module/xt_ndpi/parameters/ipv6:0
/sys/module/xt_ndpi/parameters/l4mismatch:3
/sys/module/xt_ndpi/parameters/l4mis_size:312
/sys/module/xt_ndpi/parameters/lib_trace:4
/sys/module/xt_ndpi/parameters/max_parsed_lines:0
/sys/module/xt_ndpi/parameters/max_unk_other:20
/sys/module/xt_ndpi/parameters/max_unk_tcp:20
/sys/module/xt_ndpi/parameters/max_unk_udp:20
/sys/module/xt_ndpi/parameters/mtu:48000
/sys/module/xt_ndpi/parameters/ndpi_enable_flow:1
/sys/module/xt_ndpi/parameters/ndpi_flow_limit:10000000
/sys/module/xt_ndpi/parameters/ndpi_match:342238
/sys/module/xt_ndpi/parameters/ndpi_size_flow_struct:704
/sys/module/xt_ndpi/parameters/ndpi_size_hash_ip4p_node:44
/sys/module/xt_ndpi/parameters/ndpi_stun_cache:0
/sys/module/xt_ndpi/parameters/noncached:21196
/sys/module/xt_ndpi/parameters/nonip:0
/sys/module/xt_ndpi/parameters/non_tcpudp:104440
/sys/module/xt_ndpi/parameters/skb_lin:13798
/sys/module/xt_ndpi/parameters/skb_seg:7398
/sys/module/xt_ndpi/parameters/tls_buf_size:4
/sys/module/xt_ndpi/parameters/xt_debug:3

I am puzzled, but also hope to guide,Thank you very much

[vel21ripn]

Thanks for the detailed report. I tried to fix this error in commit f29651a

[someonebw]

Thank you very much for your hard work to solve this problem in such a short time.
You are so efficient;
Thank you again for everything you've done for us.

[someonebw]

Using the latest version of the program, I re-tested it.

#in my test nat server
[root@ecs-gre-xw example]# ./ndpiReader |more
Welcome to nDPI 4.3.0-3720-f29651a0

#iptables command for test;drop mining in FORWARD chain
#iptables -I FORWARD -m ndpi --proto mining -j REJECT
[root@ecs-gre-xw example]# iptables -nvL
Chain INPUT (policy ACCEPT 53256 packets, 3051K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 7720 packets, 646K bytes)
pkts bytes target prot opt in out source destination
124 5952 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi protocol mining reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 78322 packets, 56M bytes)
pkts bytes target prot opt in out source destination

#in my client for use command visit mining ip

[root@ecs-7e68 ~]# curl --interface 192.168.92.66 https://51.15.119.157
curl: (7) Failed connect to 51.15.119.157:443; Connection refused
[root@ecs-7e68 ~]# curl --interface 192.168.92.66 https://51.15.119.157
curl: (7) Failed connect to 51.15.119.157:443; Connection refused

#nat server ；you can see flows ！The mining protocol is correctly identified
[root@ecs-gre-xw example]# cat /tmp/flows
Every 1.0s: cat /proc/net/xt_ndpi/flows ecs-gre-xw: Mon Apr 18 12:48:43 2022
TIME 1650257323
1650257323 1650257323 4 6 192.168.92.66 44221 51.15.119.157 443 48 0 1 0 I=4 P=Mining,TLS

#client cap ;can see;
#You can see that the rule is in effect, successfully intercepting the package of the mining protocol.
#id 51 is the gw use reject packet to client

[root@ecs-7e68 tmp]# tshark -r drop.pcap
Running as user "root" and group "root". This could be dangerous.
50 12 192.168.92.66 -> 51.15.119.157 TCP 62 canto-roboflow > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2048
51 12 192.168.92.110 -> 192.168.92.66 ICMP 90 Destination unreachable (Port unreachable)

But here, I have a question, right?
Why in /proc/net/xt_ndpi/proto
the count don't add up?always is 0 ？Is that normal? Is it statistical into other types?

[root@ecs-gre-xw ~]# cat /proc/net/xt_ndpi/proto |grep mining
#id mark ~mask name # count #version 4.3.0-3720-f29651a0
2a 2a/000001ff mining # 0 debug=3

#message in nat server
17146972:Apr 18 12:49:46 ecs-gre-xw kernel: START target ct_ndpi 00000000b63f22fb ct 00000000570c1be0 proto 6 192.168.92.66:44221 -> 51.15.119.157:443 DIR
17147118:Apr 18 12:49:46 ecs-gre-xw kernel: Reuse ct_ndpi 00000000b63f22fb ct 00000000570c1be0 proto 6 192.168.92.66:44221 -> 51.15.119.157:443 DIR
17147259:Apr 18 12:49:46 ecs-gre-xw kernel: START match skb 0000000033b16224 ct 00000000570c1be0 proto 6 192.168.92.66:44221 -> 51.15.119.157:443 len 48 [42,91,Match by IP] DIR
17147428-Apr 18 12:49:46 ecs-gre-xw kernel: cached dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
17147547:Apr 18 12:49:46 ecs-gre-xw kernel: cache skb 0000000033b16224 ct 00000000570c1be0 proto 6 192.168.92.66:44221 -> 51.15.119.157:443 len 48 [42,91,Match by IP]
17147713-Apr 18 12:49:46 ecs-gre-xw kernel: inprogress dc:0 ex:0000000000000010000000000000000000000000000000000000020000080000
17147833:Apr 18 12:49:46 ecs-gre-xw kernel: match_done skb 0000000033b16224 ct 00000000570c1be0 proto 6 192.168.92.66:44221 -> 51.15.119.157:443 len 48 [42,91,Match by IP] result 1
17148008-Apr 18 12:49:46 ecs-gre-xw kernel: ndpi:ns0 free_flow ct pK-error ct_ndpi (einval) flow

[vel21ripn]

Fixed in 1367ad9

[someonebw]

Thank you , vel21ripn for your contribution.
Perfect. After bug modification, the test is completely normal.

#the last version
[root@centos8 example]# ./ndpiReader
Welcome to nDPI 4.3.0-3721-1367ad9b

#Client before testing
[root@centos8 example]# cat /proc/net/xt_ndpi/proto |more
#id mark ~mask name # count #version 4.3.0-3721-1367ad9b

#after client test for visit mining's ip
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 48 debug=3

#The client effect is as follows:
[root@centos8 ~]# ./client.http.mining.sh
curl: (7) Failed to connect to 3.11.147.67 port 80: Connection refused
curl: (7) Failed to connect to 3.209.45.79 port 80: Connection refused
curl: (7) Failed to connect to 13.93.54.137 port 80: Connection refused
curl: (7) Failed to connect to 18.138.108.67 port 80: Connection refused
curl: (7) Failed to connect to 18.168.182.86 port 80: Connection refused
curl: (7) Failed to connect to 18.218.250.66 port 80: Connection refused
curl: (7) Failed to connect to 34.255.23.113 port 80: Connection refused
curl: (7) Failed to connect to 35.158.244.151 port 80: Connection refused
curl: (7) Failed to connect to 51.15.116.226 port 80: Connection refused
curl: (7) Failed to connect to 51.15.119.157 port 80: Connection refused
curl: (7) Failed to connect to 51.141.78.53 port 80: Connection refused
curl: (7) Failed to connect to 52.3.158.184 port 80: Connection refused
curl: (7) Failed to connect to 52.14.151.177 port 80: Connection refused
curl: (7) Failed to connect to 52.169.42.101 port 80: Connection refused
curl: (7) Failed to connect to 52.176.7.10 port 80: Connection refused
curl: (7) Failed to connect to 52.176.100.77 port 80: Connection refused
curl: (7) Failed to connect to 52.187.207.27 port 80: Connection refused
curl: (7) Failed to connect to 52.231.165.108 port 80: Connection refused
curl: (7) Failed to connect to 52.232.243.152 port 80: Connection refused
curl: (7) Failed to connect to 94.237.54.114 port 80: Connection refused
curl: (7) Failed to connect to 104.42.217.25 port 80: Connection refused
curl: (7) Failed to connect to 159.89.28.211 port 80: Connection refused
curl: (7) Failed to connect to 191.234.162.198 port 80: Connection refused
curl: (7) Failed to connect to 192.81.208.223 port 80: Connection refused

[someonebw]

Hello Vel21RIPn, today I have a test and found a problem.

//in nat server
#the last version
[root@centos8 example]# ./ndpiReader
Welcome to nDPI 4.3.0-3721-1367ad9b

#Client before testing
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3

#iptables status before testing
#iptables -I FORWARD -m ndpi --proto mining -p tcp -j REJECT --reject-with tcp-reset
#before the test
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi protocol mining reject-with tcp-reset

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

// in client,i use iperf3 client to test something.but ndpi reset my session.
[root@centos8 ~]# iperf3 -c x.x.x.x -p 38005
iperf3: error - unable to connect to server: Connection refused
[root@centos8 ~]# date
Sun Apr 24 11:29:13 CST 2022

//before the test;in nat server iptabels status
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi protocol mining reject-with tcp-reset

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

//after the test ; 1 packets match in forward ;
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1 60 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi protocol mining reject-with tcp-reset

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[root@centos8 ~]# date
Sun Apr 24 11:29:11 CST 2022

//but no counter in mining.
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3

//nat server dmesg;protocol is match Unknown
[233284.167586] Create ct_ndpi 000000006506e677 ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 DIR
[233284.167608] START match skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown] DIR
[233284.167660] process skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown]
[233284.167892] match_done skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown] result 1
[233284.168305] Reuse ct_ndpi 000000006506e677 ct 0000000049954a09 proto 6 x.x.x.x:38005 -> 172.19.100.240:39074 REV
[233284.168354] Reuse ct_ndpi 000000006506e677 ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 DIR
[233284.168361] START match skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown] DIR
[233284.168371] cache skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown]
[233284.168382] match_done skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown] result 1
[233284.168428] Reuse ct_ndpi 000000006506e677 ct 0000000049954a09 proto 6 x.x.x.x:38005 -> 172.19.100.240:39074 REV
[233284.168447] START match skb 00000000d3e31ca8 ct 0000000049954a09 proto 6 x.x.x.x:38005 -> 172.19.100.240:39074 len 40 [0,0,Unknown] REV
[233284.168456] process skb 00000000d3e31ca8 ct 0000000049954a09 proto 6 x.x.x.x:38005 -> 172.19.100.240:39074 len 40 [0,0,Unknown]
[233284.168485] match_done skb 00000000d3e31ca8 ct 0000000049954a09 proto 6 x.x.x.x:38005 -> 172.19.100.240:39074 len 40 [0,0,Unknown] result 1

However, I can see in the DMESG information on the NAT server side that I am right
The protocol identifies the access to iperf3 Server as Unknown
It's not a mining agreement. Why is the FORWARD matched?

But at this time, I have simulated access to the Mining protocol in NAT Server
Can be intercepted correctly,
In the proc proto, it can also be counted correctly.

Why do I FORWARD chain Unknown protocols
Does the rule inside match?

It's my use of the rule. Any questions?

[vel21ripn]

I suspect that in the latest changes there is some kind of error in the logic of work. I'm currently trying to make debug output more configurable.
I have question about command "iperf3 -c x.x.x.x -p 38005". Address x.x.x.x is in mining list?

[someonebw]

Thanks for taking the time to answer my questions, Vel21RIPn:

      x.x.x.x is not mining ip;        just a  normal ip;

#At the time of
#dmesg in nat server
[233284.167586] Create ct_ndpi 000000006506e677 ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 DIR
[233284.167608] START match skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown] DIR
[233284.167660] process skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown]
[233284.167892] match_done skb 00000000bf151a9b ct 0000000049954a09 proto 6 172.19.100.240:39074 -> x.x.x.x:38005 len 60 [0,0,Unknown]

#At the time of
//nat ndpi count status
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3

[vel21ripn]

Please check commit 447265b

[someonebw]

hi,vel21ripn

This version seems to have changed a lot. Thank you for your quiet efforts
I took relevant tests at the first time, but I felt a little confused
I don't know, is my rule configuration wrong, or something.

//////////////the test A

//nat server
[root@centos8 nDPI]# cat /proc/net/xt_ndpi/proto |more
#id mark ~mask name # count #version 4.3.0-3723-447265b9

//see counter for mining
[root@centos8 nDPI]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3

//some one ip in Mining's IP pool.
[root@centos8 ~]# cat /proc/net/xt_ndpi/ip_proto |grep 3.11.147.67
3.11.147.67 Mining

//my iptables rule.just want to drop mining proto.
[root@centos8 nDPI]# iptables -A FORWARD -m ndpi --proto mining -p tcp -j REJECT --reject-with tcp-reset
[root@centos8 nDPI]# clear
[root@centos8 nDPI]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 ndpi proto mining reject-with tcp-reset

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

//client ;test command is so sample
cat http://3.11.147.67

//////////////Test A results.
It feels that the Mining protocol is not matched.

According to my understanding, the normal process should be that after Mining's IP is matched,
It will definitely go into the mining proto, and then match the rules in the forward
Get rid of.

[root@centos8 ~]# cat /proc/net/xt_ndpi/ip_proto |grep 3.11.147.67
3.11.147.67 Mining
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 67625 packets, 2812K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 1046 packets, 79883 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto mining reject-with tcp-reset

Chain OUTPUT (policy ACCEPT 128K packets, 32M bytes)
pkts bytes target prot opt in out source destination

nat-server-dmesg-for-test-a.txt

So, I wonder if there's something wrong with my rule. I tried another rule

//////////////the test B

//nat server
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 67866 packets, 2825K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 1046 packets, 79883 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi inprogress mining
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi clevel dpi proto mining
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto unknown

Chain OUTPUT (policy ACCEPT 128K packets, 32M bytes)
pkts bytes target prot opt in out source destination

//client ;test command is so sample
cat http://3.11.147.67

//////////////Test B results.
The test result is the same as test A. The protocol is also not identified.

[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep mining
2a 2a/000001ff mining # 0 debug=3
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 68214 packets, 2844K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 1050 packets, 80123 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi inprogress mining
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi clevel dpi proto mining
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto unknown

Chain OUTPUT (policy ACCEPT 129K packets, 32M bytes)
pkts bytes target prot opt in out source destination

nat-server-dmesg-for-test-b.txt

So I went on to do test C
//////////////Test C
//nat server
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 68629 packets, 2865K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 1085 packets, 83744 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi inprogress http
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi clevel dpi proto http
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto unknown

Chain OUTPUT (policy ACCEPT 129K packets, 32M bytes)
pkts bytes target prot opt in out source destination

//client
curl http://www.bing.com

//////////////Test C results.
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep http
07 7/000001ff http # 0 debug=0
[root@centos8 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 69339 packets, 2902K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 1129 packets, 87871 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi inprogress http
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi clevel dpi proto http
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto unknown

Chain OUTPUT (policy ACCEPT 130K packets, 32M bytes)
pkts bytes target prot opt in out source destination

nat-server-dmesg-for-test-c.txt

Three tests, all without success.
What exactly is the problem? What's wrong with my rules?

---

Finally, few small point.

//Question 1
[root@centos8 ~]# cat /proc/net/xt_ndpi/proto |grep https
[root@centos8 ~]#

[root@centos8 ~]# iptables -m ndpi --help |grep https
[root@centos8 ~]#

no https.
but i see https,in
https://github.com/vel21ripn/nDPI/blob/flow_info-4/ndpi-netfilter/INSTALL
//

//Question 2

[vel21ripn]

"cat http://3.11.147.67/" may be "curl http://3.11.147.67/" ?
I can't reproduce your result.

wget  -Y off http://3.11.147.67
--2022-05-04 11:12:58--  http://3.11.147.67/
Connecting to 3.11.147.67:80... failed: Connection refused.
root@ls-gw-r2:~# iptables -nvxL
Chain INPUT (policy ACCEPT 101 packets, 18927 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 CL         all  --  srv    *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 658370 packets, 744247629 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       1       60 CL         all  --  srv    *       0.0.0.0/0            0.0.0.0/0           
       0        0 CL         all  --  *      srv     0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 20 packets, 2344 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       1       40 CL         all  --  *      srv     0.0.0.0/0            0.0.0.0/0           

Chain CL (4 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0            udp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* t_udp */
       2      100            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* t_tcp */
       1       60 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            ndpi proto mining reject-with tcp-reset

dmesg

May  4 11:12:50 ls-gw-r2 kernel: xt_ndpi v1.2 ndpi 4.3.0-3723-447265b IPv6=YES debug_message=YES
May  4 11:12:50 ls-gw-r2 kernel:  BT: hash_size 14k, hash_expiation 2100 sec, log_size 128kb
May  4 11:12:50 ls-gw-r2 kernel:  sizeof hash_ip4p_node=44 flow_struct=704 packet_struct=1424
May  4 11:12:50 ls-gw-r2 kernel:    flow_tcp_struct=136 flow_udp_struct=88 int_one_line_struct=16
May  4 11:12:50 ls-gw-r2 kernel:  ndpi_ip_addr_t=16 ndpi_protocol=4 nf_ct_ext_ndpi=176
May  4 11:12:50 ls-gw-r2 kernel:  flow_info=112 spinlock_t=4  NF_EXT_ID 7
May  4 11:12:50 ls-gw-r2 kernel: xt_ndpi: MAX_PROTOCOLS 512 LAST_PROTOCOL 285
May  4 11:12:50 ls-gw-r2 kernel: xt_ndpi: flow acctounting ON
May  4 11:12:51 ls-gw-r2 kernel: parse_ndpi_flow:ns0 set timeout=330
May  4 11:12:51 ls-gw-r2 kernel: parse_ndpi_flow:ns0 set limit=400000
May  4 11:12:51 ls-gw-r2 kernel: nflow_proc_close:ns0 view 0 dumped 0 deleted 0
May  4 11:12:53 ls-gw-r2 kernel: e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
May  4 11:12:53 ls-gw-r2 kernel: br0: port 1(eth1) entered blocking state
May  4 11:12:53 ls-gw-r2 kernel: br0: port 1(eth1) entered forwarding state
May  4 11:12:58 ls-gw-r2 kernel: <START match  skb d261fa65 ct  d02e130 proto 6 10.249.0.2:49288 -> 3.11.147.67:80 len 60 [0,0,Unknown] DIR
May  4 11:12:58 ls-gw-r2 kernel:  Create   ct_ndpi 268e1d6e ct  d02e130 proto 6 10.249.0.2:49288 -> 3.11.147.67:80 DIR
May  4 11:12:58 ls-gw-r2 kernel:  newpkt   ct_ndpi 268e1d6e ct  d02e130 proto 6 10.249.0.2:49288 -> 3.11.147.67:80 DIR
May  4 11:12:58 ls-gw-r2 kernel:  check_known4 skb d261fa65 ct  d02e130 proto 6 10.249.0.2:49288 -> 3.11.147.67:80 len 60 [0,0,Unknown]  clevel 2 [42]
May  4 11:12:58 ls-gw-r2 kernel:  ndpi_process_packet dpi: g_pr:7 g_host_pr:42 m:0 a:0 cl:Unknown; ct: m:0 a:0 cl:Unknown pcnt 0 [0,0]
May  4 11:12:58 ls-gw-r2 kernel: check_guessed_protocol:  ct_clevel 0, proto.app 0, flow clevel 0, g_host_id 42, g_id 7
May  4 11:12:58 ls-gw-r2 kernel: check_guessed_protocol: host app_protocol 42
May  4 11:12:58 ls-gw-r2 kernel:  ndpi_match protocol: yes : master Unknown(0) app Mining(1)
May  4 11:12:58 ls-gw-r2 kernel: >END   match  skb d261fa65 ct  d02e130 proto 6 10.249.0.2:49288 -> 3.11.147.67:80 len 60 [42,0,Match by IP]  result 1
May  4 11:12:58 ls-gw-r2 kernel: <START match  skb 7e0fea86 ct  d02e130 proto 6 3.11.147.67:80 -> 10.249.0.2:49288 len 40 [42,0,Match by IP] REV
May  4 11:12:58 ls-gw-r2 kernel:  Reuse    ct_ndpi 268e1d6e ct  d02e130 proto 6 3.11.147.67:80 -> 10.249.0.2:49288 REV
May  4 11:12:58 ls-gw-r2 kernel:  newpkt   ct_ndpi 268e1d6e ct  d02e130 proto 6 3.11.147.67:80 -> 10.249.0.2:49288 REV
May  4 11:12:58 ls-gw-r2 kernel:  ndpi_process_packet dpi: g_pr:7 g_host_pr:42 m:0 a:0 cl:Match by IP; ct: m:0 a:42 cl:Match by IP pcnt 0 [0,0]
May  4 11:12:58 ls-gw-r2 kernel: check_guessed_protocol:  ct_clevel 2, proto.app 0, flow clevel 2, g_host_id 42, g_id 7
May  4 11:12:58 ls-gw-r2 kernel: check_guessed_protocol: guessed app_protocol 7
May  4 11:12:58 ls-gw-r2 kernel:  ndpi_match protocol: no : master Unknown(0) app HTTP(0)
May  4 11:12:58 ls-gw-r2 kernel: >END   match  skb 7e0fea86 ct  d02e130 proto 6 3.11.147.67:80 -> 10.249.0.2:49288 len 40 [7,0,Match by IP]  result 0

About "Do not discard all the unknown traffic"
I didn't quite accurately describe my idea. I warned you that it's a bad idea to drop packets of unknown protocols without verifying that the protocol recognition process is complete.
If the first rule is "iptables ... -m ndpi --unknown -j DROP", then this will not give the expected result.

About "cat /proc/net/xt_ndpi/proto |grep https": the https protocol has been renamed to tls.
Thank you for noticing the error.

[someonebw]

"cat http://3.11.147.67/" may be "curl http://3.11.147.67/" ?
yes ;I made a handwriting mistake

I'll test it again today.
Use your rule above.

[someonebw]

hi,vel21ripn

I tried your rule and it was ok.It seems that the problem really is my system.
I wonder if it has something to do with the default libvirtd service.

Now I am also a little confused about whether it is with my NAT server
What about the default libvirtd service above?

##test in nat server
[root@centos8 log]# iptables -nvL
Chain INPUT (policy ACCEPT 32251 packets, 1350K bytes)
pkts bytes target prot opt in out source destination
31728 1313K CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 260 packets, 25364 bytes)
pkts bytes target prot opt in out source destination
262 25524 CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 63918 packets, 19M bytes)
pkts bytes target prot opt in out source destination
63516 18M CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain CL (3 references)
pkts bytes target prot opt in out source destination
38 3876 icmp -- * * 0.0.0.0/0 0.0.0.0/0
71 6200 udp -- * * 0.0.0.0/0 0.0.0.0/0
95359 20M tcp -- * * 0.0.0.0/0 0.0.0.0/0
26 1560 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto mining reject-with tcp-reset
[root@centos8 log]# curl http://3.11.147.67
curl: (7) Failed to connect to 3.11.147.67 port 80: Connection refused
[root@centos8 log]# iptables -nvL
Chain INPUT (policy ACCEPT 32269 packets, 1351K bytes)
pkts bytes target prot opt in out source destination
31746 1314K CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 260 packets, 25364 bytes)
pkts bytes target prot opt in out source destination
262 25524 CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 63933 packets, 19M bytes)
pkts bytes target prot opt in out source destination
63532 19M CL all -- * * 0.0.0.0/0 0.0.0.0/0

Chain CL (3 references)
pkts bytes target prot opt in out source destination
38 3876 icmp -- * * 0.0.0.0/0 0.0.0.0/0
74 6434 udp -- * * 0.0.0.0/0 0.0.0.0/0
95390 20M tcp -- * * 0.0.0.0/0 0.0.0.0/0
27 1620 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 ndpi proto mining reject-with tcp-reset

#test in client server；is ok too；
[root@centos7 ~]# curl http://3.11.147.67
curl: (7) Failed connect to 3.11.147.67:80; Connection refused

so i do my rule test again；

It turns out to be ok.
That's not what happened before. It's kind of confusing。

After two tests, everything felt normal.
Mining protocol reset by my rule
Iperf3 test traffic was also not accidentally killed.
Thank you again for your detailed answer. vel21ripn