Hi, I see strange “new” connections coming from 159.148.147.229:30000 to my ip port 5678
This is probably due to discovery protocol interacting badly with connection tracking code. If I /tool/sniffer I can see request/response, but apparently, for the connection tracking machinery the request is not seen, and the response comes as a “new” connection.
Is it well known? Will it be fixed? For what I know happens in development, testing, stable and longterm.
TCP connection is considered “established” after successful completion of three-way handshake. If some remote host is probing a TCP port to check if it’s open, it might send only initial packet and wait for reply - if reply is received, port is very likely open. Since port scanners are not interested in establishing connections, they generally skip the third step …
If that is so, there’s nothing to be fixed in ROS. You should consider closing that port to internet if it0s not really needed.
Maybe I was not completely clear: the 159.148.147.229:30000 belongs to mikrotik, I think it is about /interface/detect-internet , and the protocol is UDP, no three-way handshake.
For some reason, the initial packet (from the router to the mikrotik server) is ignored by the connection tracking machinery, and the response appears to the firewall as starting an incomming connection, with connection-state=new :
[user@Mikrotik] > /tool/sniffer/quick interface=ether1 ip-address=159.148.147.229
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU, FP
INTERF TIME NU DI SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOC SI C FP
ether1 640.438 21 -> CC:2D:E0:C3:9B:90 94:6A:B0:60:CA:B9 192.168.1.33:5678 (discovery) 159.148.147.229:30000 ip:udp 74 0 no
ether1 640.516 22 <- 94:6A:B0:60:CA:B9 CC:2D:E0:C3:9B:90 159.148.147.229:30000 192.168.1.33:5678 (discovery) ip:udp 74 0 no
ether1 700.441 23 -> CC:2D:E0:C3:9B:90 94:6A:B0:60:CA:B9 192.168.1.33:5678 (discovery) 159.148.147.229:30000 ip:udp 74 0 no
ether1 700.516 24 <- 94:6A:B0:60:CA:B9 CC:2D:E0:C3:9B:90 159.148.147.229:30000 192.168.1.33:5678 (discovery) ip:udp 74 0 no
How exactly are these connections shown in connection tracking list?
I use “interval=1” to watch them appear and then quit before they timeout, and execute the line again. They appear every minute or so.
They used to appear because I have a droplist populated by new connection attempts, and when I started using it for UDP I started seeing mikortik and DNS addresses in it.
So, for some reason what the firewall sees is a connection attempt from google DNS to my machine :5678, or from Mikrotik’s :30000
[admin@Mikrotik] /> /ip/firewall/connection/print detail interval=1 where protocol=udp dst-address~"NN.NN.NN.NN:"
Flags: E - expected; S - seen-reply; A - assured; C - confirmed; D - dying; F - fasttrack; H - hw-offload; s - srcnat; d - dstnat
12 C protocol=udp src-address=8.8.8.8:53 dst-address=NN.NN.NN.NN:5678 reply-src-address=NN.NN.NN.NN:5678 reply-dst-address=8.8.8.8:53
timeout=4s orig-packets=1 orig-bytes=80 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0
repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps
[admin@Mikrotik] /> /ip/firewall/connection/print detail interval=1 where protocol=udp dst-address~"NN.NN.NN.NN:"
Flags: E - expected; S - seen-reply; A - assured; C - confirmed; D - dying; F - fasttrack; H - hw-offload; s - srcnat; d - dstnat
13 C protocol=udp src-address=159.148.147.229:30000 dst-address=NN.NN.NN.NN:5678 reply-src-address=NN.NN.NN.NN:5678
reply-dst-address=159.148.147.229:30000 timeout=9s orig-packets=1 orig-bytes=60 orig-fasttrack-packets=0 orig-fasttrack-bytes=0
repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps