Strange tftp traffic not captured using tcpdump

On one of my machines 13.2-RELEASE-p1 GENERIC amd64 for the last 24 hours I keep seeing in the log files that tcpwrappers are rejecting a tcp connection every 1 minute ( inetd[86115]: twist 206.168.34.170 to /bin/echo "You are not welcome to use tftpd from 206.168.34.170)

I have tftpd for my local network and I have ipfw to protect it also, but this is the only host that is not blocked.
My interface list:
# ifconfig -l
re0 re1 lo0 lo1 vboxnet0 tun0 wg0 tun1

I have tried
1) tcpdump -n -i re0 host 206.168.34.170
no packet . I tried every other interface re1 and also VPN interfaces, nothing happened, even though every 1 minite I see the "You are not welcome..."
2) tcpdump -n -i re0 port tftp
no packet . I tried every other interface re1 and also VPN interfaces, nothing happened, even though every 1 minute I see the "You are not welcome..."
3) ipfw add 1 deny log logamount 100 all from 206.168.34.170 to an
nothing logged on this rule, even though every 1 minute I see the "You are not welcome..."
4) I even added this rule after the divert (nat) rule. Nothing.....
5) I run tcpdump -i re0 port tftp
and can see the tftp traffic from other local lan hosts.
08:34:14.836001 IP XXXX.12369 > XXXX.tftp: 35 RRQ "/pxelinux" octet tsize 0 rollover 0
6) netstat -an | grep 206.168 is empty
(its a udp staleless so its normal).

This happens on a heavily used machine with a lof of traffic.

I was considering perhaps somehow this packes arrives from wireguard or openvpn interface encrypted and cannot be captured..

I cannot find out from what interface this packets arrive.

No other machine in the same lan reports such packet.


Any suggestions?


I am puzzled.
 
No, I don't have any tunnels. Just basic services like Openvpn, Wireguard, bind, nginx, torrent over wireguard tunnel, samba with many ipfw rules.
 
I keep seeing in the log files that tcpwrappers are rejecting a tcp connection every 1 minute ( inetd[86115]: twist 206.168.34.170 to /bin/echo "You are not welcome to use tftpd from 206.168.34.170)
Maybe I'm misunderstanding something here, but TFTP is UDP and tcpwrappers (hosts.allow) is for TCP services. Did you enable the TCP port in inetd.conf?
 
it seems it (tcpwrappers) works with udp too with some limitations (no ident support)
anyway neither his tcpdump or ipfw testing rules included the protocol so it would catch any
 
TFTP is both TCP and UDP. I believe it initiate as UDP and if the downlaod is very big it switches to TCP.

On my machine:
# grep tftp /etc/services
tftp 69/tcp #Trivial File Transfer
tftp 69/udp #Trivial File Transfer

But I have enabled only the UDP TFTP:
# grep tftp /etc/inetd.conf | grep -v '#'
tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /home/tftpboot

and checking tcp wrappers for tftp yields no error:
# tcpdchk -a | grep tftp

tcpdchk -v
>>> Rule /etc/hosts.allow line 90:
daemons: ALL
clients: ALL
option: severity auth.info
option: twist /bin/echo "You are not welcome to use daemon_name from client_hostname - client_addr."
access: granted



Meanwhile every minute the syslog reports:
Sep 9 12:51:16 bigb5 inetd[13244]: twist 206.168.34.170 to /bin/echo "You are not welcome to use tftpd from 206.168.34.170 - 206.168.34.170."

Just in 13 hours I have 4366 hits:

# grep "tftpd from 206.168.34.170" /var/log/all.log | wc -l
4366
# grep "tftpd from" /var/log/all.log | wc -l
4378

(so must of TFTPD usage is from that host).

I changed a bit the message on "You are not welcome to ..." to "You are not welcome on my computer to use..." and the new message was appeared in the syslog just to test that it reads the correct hosts.allow.


I am starting to believe that if I reboot I will stop receiving this message. Somethng stuck in the networking code?
 
TFTP is both TCP and UDP. I believe it initiate as UDP and if the downlaod is very big it switches to TCP.
Can't find an RFC that defines this. As far as I know TFTP is UDP only.

On my machine:
# grep tftp /etc/services
tftp 69/tcp #Trivial File Transfer
tftp 69/udp #Trivial File Transfer
Just because a TCP port is reserved doesn't mean the protocol actually uses it.
 
This machine is not on my lan. My lan starts from 83.212.XX.XX
It is over 20 hops distance in traceroute.
Of course arp -an does not displays anything about nodes not on 83.212.XX

Meanwhile the packets keep arriving....
# grep "tftpd from 206.168.34.170" /var/log/all.log | wc -l
5122

Also, even though multiple packets are comming from that host for tftp, only one packet got rejected when it tried to access other port

Sep 9 12:29:15 XXXX kernel: ipfw: 1 Deny TCP 206.168.34.170:11059 <myIP>:427 in via re0


I have the rule

# ipfw show 1
00001 1 60 deny log logamount 100 ip from 206.168.34.170 to any



So many packets are comming from that IP for tftpd, only (1 every minute) one only got rejected and logged ~ 3 hours ago.
 
I cannot find out from what interface this packets arrive.

No other machine in the same lan reports such packet.
Did you check that vboxnet0 interface? Maybe it's a VM that runs on the machine? Or the booting of one of them? (maybe it tries a PXE boot?)
 
I continue to receive such messages in the syslog, but no packet capture at every interface my system has. I am attaching the picutre where these messages do appear, and also using tmux with tcpdump at each interface where no packets are being captured. Thus I am incling to believe that something is stuck in the system and keeps repeating a message.




1725900190148.png







1725900356350.png
 
use -l (lowercase L) with tcpdum to see in real time. otherwise it waits until some buffer fills up and might take a whilte
 
OK, I executed the same commands to capture traffic at every interface adding -l (lowercase L). But nothing ever logged and syslog keeps writing this message.

I even decided to modify the hosts.allow and added a rule for
ALL: 206.168.34.170: allow

and then the syslog wrote:

Sep 9 21:40:19 bigb5 tftpd[76240]: 206.168.34.170: read request for /a: File not found


and then the re0 card captured just a reply:

# tcpdump -l -i re0 host 206.168.34.170
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:40:19.348982 IP XXXX.33127 > 206.168.34.170.27089: UDP, length 19
21:40:19.504997 IP 206.168.34.170 > XXXX: ICMP 206.168.34.170 udp port 27089 unreachable, length 55


nothing else was captured.


Then I deleted the allow rule for the IP 206.168.34.170 .

and nothing was logged at the syslog for that IP during the last 15 minutes (it was used to be a request every minute).



and just like that everything went normal....
 
Back
Top