Does Win 10 not pass through packets destined for Unix sockets?

Question

In summary I have a linux pxe server setup that I now need to use on some windows 10 laptops so for the fastest and most efficient development effort I am attempting to simply move the linux pxe server I already have built to a virtual machine I launch from virtualbox on the win 10 laptops. Early signs were positive and I am able to pass my dhcpd service through a bridged connection to the Ethernet on the host and the client(which is also a headless linux system) receives an ip address and the next server address and proceeds to the tftp server for the pxelinux.0 file. This is where I have issues, the following occurs

1. Client sends dhcp discover and passes through win 10 to linux dhcpd server and receives an ip address.
2. client gets ip for the next server = tftp server and the next file = "pxelinux.0"
3. client times out waiting for pxelinux.0 file - wireshark on pxe server reveals never receives tftp read request for the file.

Things I have verified.

• services up Dhcpd, nfs and tftp.socket listening and ss command shows tftp listening as well

tftp.service - Tftp Server
     Loaded: loaded (/usr/lib/systemd/system/tftp.service; indirect; vendor pre>
     Active: inactive (dead)
TriggeredBy: ● tftp.socket
       Docs: man:in.tftpd
lines 1-5/5 (END)
systemctl status tftp.socket
● tftp.socket - Tftp Server Activation Socket
     Loaded: loaded (/usr/lib/systemd/system/tftp.socket; enabled; vendor prese>
     Active: active (listening) since Tue 2022-07-19 12:50:17 CDT; 23min ago
   Triggers: ● tftp.service
     Listen: [::]:69 (Datagram)
      Tasks: 0 (limit: 11004)
     Memory: 4.0K
        CPU: 252us
     CGroup: /system.slice/tftp.socket

Jul 19 12:50:17 fedora systemd[1]: Listening on Tftp Server Activation Socket.
lines 1-11/11 (END)
ss -lu
State   Recv-Q  Send-Q    Local Address:Port        Peer Address:Port  Process  
UNCONN  0       0               0.0.0.0:48494            0.0.0.0:*              
UNCONN  0       0         127.0.0.53%lo:domain           0.0.0.0:*              
UNCONN  0       0             127.0.0.1:323              0.0.0.0:*              
UNCONN  0       0               0.0.0.0:mdns             0.0.0.0:*              
UNCONN  0       0               0.0.0.0:hostmon          0.0.0.0:*              
UNCONN  0       0                     *:tftp                   *:*              
UNCONN  0       0                     *:tftp                   *:*              
UNCONN  0       0                 [::1]:323                 [::]:*              
UNCONN  0       0                  [::]:36714               [::]:*              
UNCONN  0       0                  [::]:mdns                [::]:*              
UNCONN  0       0                  [::]:hostmon             [::]:*   

• nfs exports allows any ip to look at the directory with no root squash

correct/directory/to/tftpboot/  *(rw, no_root_squash)
correct/directory/to/image/root/ *(rw, no_root_squash)

So to me I am ready to recieve and listen on the linux side, My Question is: Does windows alter/block packets that are sourced or destined for a unix socket? The tftp.socket is a unix socket so I was not sure if windows was blocking or dumping the traffic. I have done the following on the windows side to investigate.

1. Turned off all windows firewalls( made no difference)
2. Made custom rules to allow all udp messages on all ports to pass
3. Checked the windows logs to see if there were any packets dropped/blocked by the firewall , there is no mention of allowing it to pass or it being blocked in these logs which makes me wonder if the read request is even getting to windows( at least in a format that it can recognize...)

The last point makes me ask - as a bridged connection the client should see a direct path to the linux servers ip address as well as its ports just past the Ethernet ports mac address is this not correct? So to me I would have thought windows would be out of the loop completely. But I do not understand why in this case on the virtual machine I get no tftp read requests and on the regular linux server with the same client I simply start receiving tftp read requests. Any advice tips or things to check would be greatly appreciated.

Edit: Ok so I wiresharked the windows 10 side and I did see the TFTP read request coming through after not filtering for ip's. enter image description here

so are there any good ways to see if that read request actually makes it to the virtual machine through windows? And also the destination ip address for the read request is the 192.9.200.10 which is the linux pxe server so I would have thought it would bypass windows at that point, am I wrong?

Answer 1

Check the TFTPd log and see if the TFTP request really hit the daemon or not. if it does you can also see that the daemon sends an answer including the name of the file and its size. The request uses as destination UDP port 69 and as source an "ephemeral" UDP port. The daemon answer (and the future data transfer) will be sent to the client on that ephemeral port. It could be that the one that gets blocked is the TFTP Server answer and not the request.

Also check the that VM IP, the NIC IP and the Client's IP are consistent.

Edit 1:

tftpd-hpa

Logs are saved in:

/var/log/daemon.log

Turn on diagnostic logging by adding parameter -vvvv to:

/etc/default/tftpd-hpa 

If you use a different server you must find location and how to turn logging on

The rest sounds like:

1. A virtual-box issue when dealing with the NIC driver or
2. When toggling the host NIC probably your new opening traffic firewall rules were really enforced.